[SciPy-user] lapack unresolved symbol question

[Karl Young]

Thanks again Robert; I "solved" the problem inspired by your suggestion 
but maybe you or someone else has a suggestion for something more 
sensible or elegant. The problem seems to be that there's a 
liblapack.so.3 in /usr/lib (presumably not built against an 
ATLAS-accelerated LAPACK) that gets picked up if I have /usr/lib in 
LD_LIBRARY_PATH . I had forgotten that I'd had this problem before and 
as a temporary solution had just taken /usr/lib out of LD_LIBRARY_PATH; 
/usr/lib got put back in as a result of installing of something else 
(hence the recurrence). Obviously removing /usr/lib from LD_LIBRARY_PATH 
isn't a great "solution" so pardon my ignorance but is there a python 
environment variable can I set to get python to look in /usr/lib/atlas 
before /usr/lib (PYTHONPATH doesn't seem to work for this) ? Thanks,

>Karl Young wrote:
>  
>
>> From googling around a bit it looks like I'm having an unresolved 
>>symbol problem that was apparently typical at one point but also 
>>apparently solved. But I can't quite pinpoint the fix so I figured I'd 
>>check re. easy fixes before rebuilding libraries and the like.
>>
>>The issues seems to be that the symbol clapack_sgesv is missing from 
>>/usr/lib/python2.4/site-packages/scipy/linalg/clapack.so
>>- apparently confirmed via nm, i.e.
>>
>>nm /usr/lib/python2.4/site-packages/scipy/linalg/clapack.so | grep 
>>clapack_sgesv
>>               U clapack_sgesv
>>00012640 d doc_f2py_rout_clapack_sgesv
>>000094c0 t f2py_rout_clapack_sgesv
>>    
>>
>
>It would be good to know how you built scipy and whether you built against ATLAS
>or not. Most likely, scipy got built against an ATLAS-accelerated LAPACK library
>(which has the clapack_* symbols), but the LAPACK shared library that's getting
>picked up at runtime does not have the accelerated LAPACK functions.
>
>Check what shared libraries this extension module was built with using ldd(1):
>
>[~]$ ldd $PYLIB/scipy-0.7.0.dev3435-py2.5-linux-x86_64.egg/scipy/linalg/clapack.so
>        liblapack.so.3 => /usr/lib/atlas/liblapack.so.3 (0x00002aad3362f000)
>        libf77blas.so.3 => /usr/lib/libf77blas.so.3 (0x00002aad33f87000)
>        libcblas.so.3 => /usr/lib/libcblas.so.3 (0x00002aad348af000)
>        libatlas.so.3 => /usr/lib/libatlas.so.3 (0x00002aad351d4000)
>        libgfortran.so.1 => /usr/lib/libgfortran.so.1 (0x00002aad35b3b000)
>        libm.so.6 => /lib/libm.so.6 (0x00002aad35dd6000)
>        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002aad36058000)
>        libc.so.6 => /lib/libc.so.6 (0x00002aad36266000)
>        libblas.so.3 => /usr/lib/atlas/libblas.so.3 (0x00002aad365b8000)
>        libg2c.so.0 => /usr/lib/libg2c.so.0 (0x00002aad36f56000)
>        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
>
>Check whichever liblapack library you have for the clapack_sgesv symbol. The .so
>is often stripped of symbols, but if you have a liblapack.a file that goes with
>it, you can check that, instead:
>
>[~]$ nm /usr/lib/atlas/liblapack.so.3 | grep clapack_sgesv
>nm: /usr/lib/atlas/liblapack.so.3: no symbols
>[~]$ nm /usr/lib/atlas/liblapack.a | grep clapack_sgesv
>clapack_sgesv.o:
>0000000000000000 T clapack_sgesv
>
>  
>


-- 

Karl Young
Center for Imaging of Neurodegenerative Diseases, UCSF          
VA Medical Center (114M)              Phone:  (415) 221-4810 x3114  lab        
4150 Clement Street                   FAX:    (415) 668-2864
San Francisco, CA 94121               Email:  karl young at ucsf edu