[Numpy-discussion] Wrong lapack version detection (32/64bits)

Xavier Gnata gnata@obs.univ-lyon1...
Fri Jul 20 05:20:05 CDT 2007


>>> Hi,
>>>
>>> I'm trying to update numpy by compiling the up to date svn:
>>>
>>> I get this error :
>>> gcc: numpy/linalg/lapack_litemodule.c
>>> gcc -pthread -shared 
>>> build/temp.linux-i686-2.4/numpy/linalg/lapack_litemodule.o 
>>> -lmkl_lapack32 -lmkl_lapack64 -lmkl -lvml -lguide -lpthread -o 
>>> build/lib.linux-i686-2.4/numpy/linalg/lapack_lite.so
>>> /usr/bin/ld: cannot find -lmkl_lapack64
>>> collect2: ld returned 1 exit status
>>> /usr/bin/ld: cannot find -lmkl_lapack64
>>> collect2: ld returned 1 exit status
>>> error: Command "gcc -pthread -shared 
>>> build/temp.linux-i686-2.4/numpy/linalg/lapack_litemodule.o 
>>> -lmkl_lapack32 -lmkl_lapack64 -lmkl -lvml -lguide -lpthread -o 
>>> build/lib.linux-i686-2.4/numpy/linalg/lapack_lite.so" failed with exit 
>>> status 1
>>>
>>> There must be something wrong in the distutils/makefile because I'm on a 
>>> debian sid *i386* so why should I link against mkl_lapack64 ??
>>> Of course, I do not have lapack64 installed on this i386 machine.
>>> I have try to simply fix that in the config file of numpy replacing 
>>> lapack64 by lapack32 everywhere but it fails (and it is not an acceptable fix).
>>>
>>> Can anyone reproduce that??
>>>
>>> Xavier
>>>
>>>
>>>   
>>>     
>>>       
>> Trying to modify  /numpy/distutils/system_info.py this way (only for 
>> test purpose...):
>>
>> #           lapack_libs = 
>> self.get_libs('lapack_libs',['mkl_lapack32','mkl_lapack64'])
>>             lapack_libs = self.get_libs('lapack_libs',['mkl_lapack32'])
>>
>> I'm able to compile numpy but import numpy fails:
>>
>>   
>>     
> svn numpy and scipy work perfectly on Ubuntu, and there are no 
> noticeable differences between sid and Ubuntu to make a difference a priori.
>
> Do you have the mkl installed at all on your computer ?

Ok I have mkl installed on my machine (it has by installed by a well 
know closed sources software....)
/usr/lib/libmkl.so: ELF 32-bit LSB shared object, Intel 80386, version 1 
(SYSV), not stripped
/usr/lib/libmkl_lapack32.so: ELF 32-bit LSB shared object, Intel 80386, 
version 1 (SYSV), not stripped


I just cannont remove them (because I will break another part of my 
system) but anyway, numpy detects them in a wrong way : I have no 64 
version of mkl on this i386 machine :)) I have try to remove them and 
numpy compiles/works again but it is not a solution.

I also have debian lapack package installed /usr/lib/liblapack.so.3.0. 
Numpy used to detect/use only this debian version of lapack.

I never had a cusomized version of site.cfg.
I have seen some recent changes (svn commits) on the way numpy detects 
the libs so it looks like we have a bug here when both 
libmkl_lapack32.so and liblapack.so (debian) are installed.

I just would like to be able to tell numpy to use liblapack.so instead 
of this non free libmkl_lapack32.so


Xavier


>  If not, and 
> without any modification to the site.cfg of numpy, I don't see why numpy 
> would try to detect the mkl. Maybe some really recent (eg a few days) 
> changes in the trunk ? I build quite regularly the lastest numpy 
> (several times / week) on Ubuntu without problems.
>   
>> ImportError: 
>> /usr/lib/python2.4/site-packages/numpy/linalg/lapack_lite.so: undefined 
>> symbol: zgesdd_
>>
>> Looks like the procedure to detect the lapack version is fully buggy (or 
>> maybe the lapack debian pacakges??)
>>   
>>     
> Quite the contrary: debian LAPACK packages were the only ones working 
> properly for a long time.
>
> David
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
>   


-- 
############################################
Xavier Gnata
CRAL - Observatoire de Lyon
9, avenue Charles André
69561 Saint Genis Laval cedex
Phone: +33 4 78 86 85 28
Fax: +33 4 78 86 83 86
E-mail: gnata@obs.univ-lyon1.fr
############################################ 



More information about the Numpy-discussion mailing list