Frank Lagor wrote: > Problem solved-- This posting is just to complete the thread to > document it if others have similar issues.
Glad you could solve it. > > The previous error: > ImportError: liblapack.so: cannot open shared object file: No such > file or directory > > was solved simply by checking that the environment variables were set > properly. I set BLAS, LAPACK, and LD_LIBRARY_PATH variables (I'm not > sure if the LD one was needed, but this worked) Yes, the LD_ is necessary (LD stands for loader). > > The next issue I ran into was that the error message changed to > "undefined symbol _dgesdd", > which I googled and discovered was a routine for singular value > decomposition that was missing-- meaning that my liblapack.so file was > incomplete. I checked this by doing > $ strings liblapack.so | grep dgesdd Note that strings is not really the best way to check that: nm is. strings only look for strings in the binary, and does not look for symbols (e.g. you could find a string which does not correspond to a function the loader and/or the linker can find). > and noticing that the output was blank. The output was not blank > however in the lapack _LINUX.a install from the netlib lapack, so that > meant that my ATLAS install was incorrect. I changed the way that I > specified the configure for ATLAS. I had to use the > --with-netlib-lapack option (as stated in one of the installation > files) instead of the "-Ss flapack pathname" Ah yes, I could never manage to make this option work either. I always use --with-netlib-lapack when I need to build a custom ATLAS. cheers, David _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
