[SciPy-user] Problems compiling scipy on SuSE 10.2

David Cournapeau david@ar.media.kyoto-u.ac...
Sat Jun 16 04:09:00 CDT 2007


Karl Edler wrote:
> Hello,
>
> Recently I tried installing scipy from rpm packages on SuSE 10.2 (64bit)
> and failed. Now I have tried compiling scipy and have run into some
> problems.
I solved yesterday the problem preventing the build of scipy on 64 bits 
arch on opensuse. Now, the rpm are available in ashigabou; not having an 
install of opensuse 64 bits available, I cannot say if they work correctly.
>
> I compiled atlas successfully and copied its *.a files to /usr/lib64/atlas
>
> I ran "python setup.py build" in the scipy directory and the build
> failed since it couldn't find the -lgcc_s library. I made a symbolic
> link from /lib64/libgcc_s.so.1 -> /lib64/libgcc_s.so and the build was
> able to proceed.
>
> Now the build fails with something about -fPIC which I don't understand.
> Here is the last bit of the output from "python setup.py build" (notice
> : relocation R_X86_64_PC32 against `atl_f77wrap_dscal__' can not be used
> when making a shared object; recompile with -fPIC):
If you are not familiar with compiling big softwares by yourself, atlas 
+blas/lapack is certainly one of the most painful experience you can 
get; those are really difficult beasts to compile right, and one wrong 
step somewhere can make fail the process much later.

Now, since you are willing to do it, here is the explanation. Assuming 
you know the difference between static (.a) and shared library (.so), 
you need to know that they need to be compiled differently: this is the 
-fPIC thing. That is, if you build an object file without the -fPIC 
option, say foo.o, the object file will *not* be usable to build any 
shared library (you cannot use it to build a .so; for a .a, it does not 
matter; this is oversimplication, but I hope you wil bear them for the 
current issue). The only way is to recompile it. If you don't understand 
the above, this is a good explanation on how things work on unix 
generally: 
http://users.actcom.co.il/~choo/lupg/tutorials/libraries/unix-c-libraries.html 


To go back to our problem: you built a static library (that's what atlas 
builds by default), and you want to use it to build a python module 
(which is a shared library on linux). That does not work. Actually, it 
sometimes work because to complicate the matter, the -fpic is not really 
necessary on x86, but is necessary for x86_64... This makes me realize 
that I don't understand how static atlas can work on this platform (the 
only way I see is to statically link atlas to the python extension, 
something which distutils does not seem to know how to do if I belive 
the log you pasted here).

Concretely: you need to rebuild atlas, which unfortunately means 
rebuilding lapack too, since atlas does not implement full lapack. Here 
are the steps:

Build lapack:
   - in make.inc, add -fPIC OPTS and NOOPTS
   - in make.inc, set LAPACKLIB to liblapack_pic.a
   - in make.inc, set FORTRAN and LOADER to g77.

Then rebuild everything the whole lapack (really be sure to rebuild 
everything).

Build Atlas:
   - extract atlas (a recent version)
   - create a directory like MyObj inside, and go inside
   - use the following options for configure: ../configure 
--with-netlib-lapack=LAPACK -C if g77 -Fa al -fPIC. LAPACK should be 
replaced by the full path of liblapack_pic.a compiled above.
   - build atlas

After, do as before. Note that you still does not use atlas as shared 
library, but this should make things work anyway for scipy. According to 
rex, using my script garnumpy made life easier for openSUSE:

http://www.ar.media.kyoto-u.ac.jp/members/david/archives/garnumpy-0.2.1.tbz2

This will download, configure and build a self contained scipy and all 
its dependencies (netlib blas/lapack by default, but you can use atlas 
instead by uncommenting the necessary lines in the gar.conf.mk file, as 
mentionned in the README).

David


More information about the SciPy-user mailing list