[Numpy-discussion] Numpy installation problem

David Cournapeau cournape@gmail....
Sat Jul 24 14:39:44 CDT 2010

On Sun, Jul 25, 2010 at 4:23 AM, Jonathan Tu <jhtu@princeton.edu> wrote:
> On Jul 24, 2010, at 3:08 PM, Benjamin Root wrote:
> On Fri, Jul 23, 2010 at 10:10 AM, Jonathan Tu <jhtu@princeton.edu> wrote:
>> Hi,
>> I am trying to install Numpy on a Linux cluster running RHEL4.  I
>> installed a local copy of Python 2.7 because RHEL4 uses Python 2.3.4 for
>> various internal functionalities.  I downloaded the Numpy source code using
>> svn co http://svn.scipy.org/svn/numpy/trunk numpy
>> and then I tried to build using
>> python setup.py build
>> This resulted in the following error:
>> gcc: numpy/linalg/lapack_litemodule.c gcc: numpy/linalg/python_xerbla.c
>> /usr/bin/g77 -g -Wall -g -Wall -shared
>> build/temp.linux-x86_64-2.7/numpy/linalg/lapack_litemodule.o
>> build/temp.linux-x86_64-2.7/numpy/linalg/python_xerbla.o -L/usr/lib64/ATLAS
>> -Lbuild/temp.linux-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas -lg2c
>> -o build/lib.linux-x86_64-2.7/numpy/linalg/lapack_lite.so /usr/bin/ld:
>> /usr/lib64/ATLAS/liblapack.a(dgeev.o): relocation R_X86_64_32 against `a
>> local symbol' can not be used when making a shared object; recompile with
>> -fPIC /usr/lib64/ATLAS/liblapack.a: could not read symbols: Bad value
>> collect2: ld returned 1 exit status /usr/bin/ld:
>> /usr/lib64/ATLAS/liblapack.a(dgeev.o): relocation R_X86_64_32 against `a
>> local symbol' can not be used when making a shared object; recompile with
>> -fPIC /usr/lib64/ATLAS/liblapack.a: could not read symbols: Bad value
>> collect2: ld returned 1 exit status error: Command "/usr/bin/g77 -g -Wall -g
>> -Wall -shared build/temp.linux-x86_64-2.7/numpy/linalg/lapack_litemodule.o
>> build/temp.linux-x86_64-2.7/numpy/linalg/python_xerbla.o -L/usr/lib64/ATLAS
>> -Lbuild/temp.linux-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas -lg2c
>> -o build/lib.linux-x86_64-2.7/numpy/linalg/lapack_lite.so" failed with exit
>> status 1
>> Full details of the output are attached in stdout.txt and stderr.txt. I
>> thought maybe it was a compiler error so I tried
>> python setup.py build -fcompiler=gnu
>> but this also resulted in errors as well (stdout_2.txt, stderr_2.txt).
>> I just noticed that on both attempts, it is complaining that it can't find
>> a Fortran 90 compiler. I'm not sure if I have the right compiler available.
>> On this cluster I have the following modules:
>> ------------ /usr/share/Modules/modulefiles ------------
>> dot         module-cvs  module-info modules     null        use.own
>> ------------ /usr/local/share/Modules/modulefiles ------------
>> mpich/gcc/1.2.7p1/64           openmpi/gcc-ib/1.2.3/64
>> mpich/intel/1.2.7dmcrp1/64     openmpi/gcc-ib/1.2.5/64
>> mpich/intel/1.2.7p1/64         openmpi/intel/1.2.3/64
>> mpich/pgi-7.1/1.2.7p1/64       openmpi/intel-11.0/1.2.8/64
>> mpich-debug/gcc/1.2.7p1/64     openmpi/intel-9.1/1.2.8/64
>> mpich-debug/intel/1.2.7p1/64   openmpi/intel-ib/1.1.5/64
>> mpich-debug/pgi-7.1/1.2.7p1/64 openmpi/intel-ib/1.2.3/64
>> mvapich/gcc/0.9.9/64           openmpi/intel-ib/1.2.5/64
>> mvapich/pgi-7.1/0.9.9/64       openmpi/pgi-7.0/1.2.3/64
>> openmpi/gcc/1.2.8/64           openmpi/pgi-7.1/1.2.5/64
>> openmpi/gcc/1.3.0/64           openmpi/pgi-7.1/1.2.8/64
>> openmpi/gcc-ib/1.1.5/64        openmpi/pgi-8.0/1.2.8/64
>> ------------ /opt/share/Modules/modulefiles ------------
>> intel/10.0/64/C/10.0.026       intel/9.1/64/default
>> intel/10.0/64/Fortran/10.0.026 intel-mkl/10/64
>> intel/10.0/64/Iidb/10.0.026    intel-mkl/10.1/64
>> intel/10.0/64/default          intel-mkl/9/32
>> intel/11.1/64/11.1.038         intel-mkl/9/64
>> intel/11.1/64/11.1.072         pgi/7.0/64
>> intel/9.1/64/C/9.1.045         pgi/7.1/64
>> intel/9.1/64/Fortran/9.1.040   pgi/8.0/64
>> intel/9.1/64/Iidb/9.1.045
>> If anyone has any ideas, they would be greatly appreciated! I am new to
>> Linux and am unsure how to fix this problem.
>> Jonathan Tu
> Jonathan,
> Looking at your error logs, I suspect that the issue is that the ATLAS
> libraries that were installed on your system were probably built using f90,
> and then your f77-built objects can't link against ATLAS.  Do you have admin
> access to this machine?  If possible, try using the yum package manager to
> install f90 (its availability depends on whatever RHEL license you have,
> though...).
> If you can install f90, I would then remove the numpy build directory and
> try building it again.
> I hope this helps,
> Ben Root
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> Hi Ben,
> I managed to complete my installation.  It required setting up the configure
> file to reference my local installation of Python, rather than the default
> /usr/bin/Python.  However, I would like to see whether or not I am using the
> optimized ATLAS/LAPACK libraries for my matrix computations.

Run ldd on the concerned extensions: numpy/linalg/lapack_lite.so and


More information about the NumPy-Discussion mailing list