[SciPy-dev] Re: scipy and ATLAS (in)dependency

Pearu Peterson pearu at scipy.org
Mon Oct 11 08:53:58 CDT 2004

On Mon, 11 Oct 2004, Michael Reimpell wrote:

>> Quite honestly, these days building scipy even from CVS very easy
> (...)
>> python setup.py install
> For at least some system administrators scattering files into the system
> without adequate packaging managment is not an option. Supported software has
> to fit into the system mainenance process, i.e. on most systems "apt-get
> upgrade" should keep the software up to date. At the moment scipy an its
> dependencies are not very rpm-friendly:


Btw, scipy and its dependencies are now available also as a part of Debian 
sid system thanks to José Fonseca, Alexandre Fayolle and Marco 
Presi. So, if RPM packagers would follow the above document then it should 
be possible to build RPMs without dependency conflicts.

> Numeric and SciPy both are statically linked against lapack and blas resp.
> atlas. While this may enhance speed, it also hands the architecture
> dependence over to SciPy.

And so? Any software that is linked against atlas will have this 

> The standard blas package, at least for fedora core 2, does not contain all
> libraries needed to build SciPy. Thus, this package has to be replaced which
> may interfere with other applications like octave and scilab.

To build Scipy, you'll need blas and lapack libraries as minimum. You 
don't need atlas to build Scipy.

> F2PY's setup.py has some failing preconditions about the path, when changing
> to the 'src' directory in line 49:
> "F2PY Version 2.43.239_1835
> Traceback (most recent call last):
>  File "setup.py", line 131, in ?
>    if 'install' in sys.argv and need_scipy_distutils():
>  File "setup.py", line 49, in need_scipy_distutils
>    os.chdir('src')
> OSError: [Errno 2] No such file or directory: 'src'
> Fehler: Bad exit status from /var/tmp/rpm-tmp.43647 (%install)"
> This prevents the rpm from being build.

For some reasons src/fortranobject.{c,h} files were not written to
a MANIFEST file when building RPMs with 'setup.py bdist_rpm'.
I worked around this issue that by including MANIFEST.in to MANIFEST.in.
Try F2PY-2.43.239_1844 again.

> Both, SciPy and Scipy_core have failing preconditions about the number of rpm
> packages build. E.g. on fedora core 2 the rpm packages build in
> build/bdist.linux-i686/rpm/RPMS/i386/ are SciPy-0.3.1_287.4340-1.i386.rpm and
> SciPy-debuginfo-0.3.1_287.4340-1.i386.rpm

This is either distutils or fedora core 2 issue, not Scipy. Have you tried 
building rpms for any other python package with extension modules using 
'setup.py bdist_rpm' in your system? I'll bet you'll get similar failures.

> Another minor issue is that the spelling of the package names is inconsistent:
> SciPy vs. Scipy vs. scipy.

I agree. I would drop using SciPy and use Scipy when referring to the 
project and scipy when referring to Python package.

> Ways to overcome these problems could be:
> Dynamically link atlas and lapack libraries and provide reasonable default rpm
> packages, e.g. i386, i686, athlon and x86_64, for them and standard packages
> (i386, noarch) for the rest.
> Statically link atlas and lapack libraries and provide reasonable default rpm
> packages.
> Provide src-rpm packages or spec-files.

I hope that someone who is expert in building RPMs could contribute to 
resolve this issue. I can build binaries for a general Linux system and 
make Win32 installers, but I don't have time nor resources to deal with 
RPMs myself.


More information about the Scipy-dev mailing list