ld.so.1 linker errors building numpy
I have been fighting for a couple weeks to get numpy installed, on the way to a full scipy+matplotlib system. At this point, the transcript looks something like:
python Python 2.5 (r25:51908, Sep 20 2006, 06:18:53) [GCC 3.4.6] on sunos5
from numpy import * -- stack trace, cut out except for last portion -- File "[snip]/linalg.py", line 25, in <module> from numpy.linalg import lapack_lite Import Error: ld.so.1: python: fatal: relocation error: file [snip]/numpy/linalg/lapack_lite.so: symbol s_wsfe: referenced symbol not found.
The python came from sunfreeware.com, if my sysadmin remembers right. I am attempting to build against an ATLAS 3.6.0 which I built with gcc 3.4.6, where I've added the -fPIC flag (since various previous error messages made me think numpy couldn't link to .a libraries, and I was going through tons of steps to get .so libraries from the ATLAS and LAPACK builds...) LAPACK 3.1.1, also built with 3.4.6 NumPy is from SVN (3881 from July 5, 2007), I think 1.0.4 is the version number, though it is not released--I think. This fixed some major problems with the distutils in 1.0.3. My uname -a output is SunOS 5.8 Generic_108528_29 sun4u sparc SUNW, Sun-Blade-1000 In some cases I had to take the failed build (from the numpy setup) and replace, at the linker stage, gcc -shared with CC -G (which invokes Sun's development tools linker). At that point the .so would be generated quietly and a restart of numpy's setup.py would continue fine. The machine on which I am doing all this is off-network, and it is extremely difficult to add new software to it. I've seen one post somewhere suggesting that using gnu ld might help (from binutils). I am in the process of adding it, but I'd prefer to find a way to build this without. Any suggestions would be appreciated! Any explanations would be gravy. -Park Hays
I have been fighting for a couple weeks to get numpy installed, on the way to a full scipy+matplotlib system. I tried installing numpy on a solaris machine on SPARC too, with the added difficulty to have only a local account on the machine (without a compiler: had to build my own :) )... At this point, the transcript looks something like:
python Python 2.5 (r25:51908, Sep 20 2006, 06:18:53) [GCC 3.4.6] on sunos5
from numpy import * -- stack trace, cut out except for last portion -- File "[snip]/linalg.py", line 25, in <module> from numpy.linalg import lapack_lite Import Error: ld.so.1: python: fatal: relocation error: file [snip]/numpy/linalg/lapack_lite.so: symbol s_wsfe: referenced symbol not found. I would recommend to do it step by step: - first, do not compile any blas/lapack. They are difficult to build correctly because of various issues I won't go into now; ATLAS only makes the matter worse :) - once you succeed building numpy without any blas/lapack, you can build your own blas/lapack. To build correctly with LAPACK 3.1.1, you only need to add -fPIC to OPT and NOOPT in the make.inc. For previous versions of LAPACK, this does NOT work, and the BLAS is broken in
Park Hays wrote: previous versions (you have to build BLAS separately). You can use the static archives (.a), but they HAVE to be built using -fPIC. I would recomment against using .so at first, as it adds a level of complexity. - once the above works, you can try ATLAS. I strongly recommend using the dev version of ATLAS (3.7.34 as today) because its configuration is able to handle shared library building. To build ATLAS usable by numpy/scipy, you should use the following: ./configure --with-netlib-lapack=LAPACKPATH -Fa alg -fPIC where LAPACKPATH is the full path of your static lapack library built before; you should also use the same compilers than everywhere else (this is not a must I guess, but less risk to avoid subtle issues when using different compilers). If you are willing to follow the above steps, it will be easier to debug things one after the other, I think. cheers, David
participants (2)
-
David Cournapeau -
Park Hays