Re: [Numpy-discussion] Da Blas
At 3:14 PM -0700 14/9/00,
Well, I certainly didn't mean to flame anyone in particular, so I'm sorry that Frank was offended.
Publicly apologized, and publicly accepted. I'm sorry I lost my cool. Ray Beausoleil and I are having a look at this too. He's coming at the problem from a Windows perspective, and I'm coming at it from a Linux/Unix perspective. It's going to be a little slow going for me at first, since it appears that I'm going to have to get my head around the distutils way of doing things.... Just in case it saves anyone else following a false lead, yes, there is a bug in the (Linux Mandrake 7.1; but probably any unix-ish box) compile line for building the lapack_lite.so shared library (i.e. what is generated on my box is "-L/usr/lib-llapack" which obviously is missing a blank before the "-llapack" substring). However, when I coerced the distutils system to get around that bug (by specifying "/usr/lib " with a trailing blank for the BLASLIBDIR and LAPACKLIBDIR variables in setup.py) the same problem (i.e. an "ImportError: /usr/lib/liblapack.so.3: undefined symbol: e_wsfe" in importing lapack_lite) ultimately manifested itself. So my advice is not to bother tracking that one down (although it probably should be reported as a bug in distutils, since adding that trailing blank algorithmically instead of in a user modifiable configuration string is the "right thing to do", TM.). I'm still puzzled by Thomas Breul's report of preloading an f2c library squashing the bug under RedHat 6.2(?). That does not work under Mandrake, although clearly there is some bloody symbol table missing from somewhere. The trouble is to find out where, and then to coerce distutils to deal with that in a portable way... Frank -- -- Frank Horowitz frank@ned.dem.csiro.au CSIRO-Exploration & Mining, PO Box 437, Nedlands, WA 6009, AUSTRALIA Direct: +61 8 9284 8431; FAX: +61 8 9389 1906; Reception: +61 8 9389 8421
Frank Horowitz wrote:
However, when I coerced the distutils system to get around that bug (by specifying "/usr/lib " with a trailing blank for the BLASLIBDIR and LAPACKLIBDIR variables in setup.py) the same problem (i.e. an "ImportError: /usr/lib/liblapack.so.3: undefined symbol: e_wsfe" in importing lapack_lite) ultimately manifested itself.
This problem is easily fixed (at least on linux) by performing the link of lapack_lite.so with g77 instead of gcc (this is required because the lapack and/or blas libraries are based on fortran object files...). For instance the out-of-box link command on my machine (Debian 2.2) is: gcc -shared build/temp.linux2/Src/lapack_litemodule.o -L/usr/local/lib -L/usr/lib -llapack -lblas -o build/lib.linux2/lapack_lite.so Simply change the 'gcc' to 'g77' and everything works nicely. Not sure if this is specific to Linux or not... Scott -- Scott M. Ransom Address: Harvard-Smithsonian CfA Phone: (617) 495-4142 60 Garden St. MS 10 email: ransom@cfa.harvard.edu Cambridge, MA 02138 GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989
At 11:30 AM -0400 9/15/00, Scott M. Ransom wrote:
Frank Horowitz wrote:
However, when I coerced the distutils system to get around that bug (by specifying "/usr/lib " with a trailing blank for the BLASLIBDIR and LAPACKLIBDIR variables in setup.py) the same problem (i.e. an "ImportError: /usr/lib/liblapack.so.3: undefined symbol: e_wsfe" in importing lapack_lite) ultimately manifested itself.
This problem is easily fixed (at least on linux) by performing the link of lapack_lite.so with g77 instead of gcc (this is required because the lapack and/or blas libraries are based on fortran object files...).
Good on ya, Scott. You nailed it. When I did this by hand, it worked. What I now need to figure out is how to coerce distutils into doing that automagically so others can benefit without this pain! Cheers, Frank Horowitz Dr. Frank Horowitz __ \ CSIRO Exploration & Mining ,~' L_|\ Australian 39 Fairway, PO Box 437, ;-' \ Geodynamics Nedlands, WA 6009 Australia ( \ Cooperative Phone +61 9 284 8431 + ___ / Research Fax +61 9 389 1906 L~~' "\__/ Centre frank@ned.dem.csiro.au W
On Sat, 16 Sep 2000, Frank Horowitz wrote:
At 11:30 AM -0400 9/15/00, Scott M. Ransom wrote:
Frank Horowitz wrote:
However, when I coerced the distutils system to get around that bug (by specifying "/usr/lib " with a trailing blank for the BLASLIBDIR and LAPACKLIBDIR variables in setup.py) the same problem (i.e. an "ImportError: /usr/lib/liblapack.so.3: undefined symbol: e_wsfe" in importing lapack_lite) ultimately manifested itself.
This problem is easily fixed (at least on linux) by performing the link of lapack_lite.so with g77 instead of gcc (this is required because the lapack and/or blas libraries are based on fortran object files...).
Good on ya, Scott. You nailed it. When I did this by hand, it worked. What I now need to figure out is how to coerce distutils into doing that automagically so others can benefit without this pain!
Adding "-lg2c" to the end of the gcc (not g77) link line always did the trick for me with FORTRAN libraries. I'm not sure if g77 does anything more than that compared with gcc for linking.
Cheers, Frank Horowitz
-- Robert Kern kern@caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
I have a problem that seems related to the one below. I'm trying to build and install Numeric 17.2.0 using the lapack and blas libraries under Python 2.0 on Red Hat 6.2 with the The build and install go fine, but when I run python and import LinearAlgebra, I get the following message: Python 2.0 (#1, Nov 13 2000, 14:15:52) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information.
from Numeric import * from LinearAlgebra import * Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.0/site-packages/Numeric/LinearAlgebra.py", line 8, in ? import lapack_lite ImportError: /usr/local/lib/python2.0/site-packages/Numeric/lapack_lite.so: undefined symbol: dgesvd_
I did try relinking with g77, as Scott's earlier message suggested: [root@harmony LALITE]# g77 -shared build/temp.linux-i686-2.0/Src/lapack_litemodule.o -L/usr/lib/lapack -o build/lib.linux-i686-2.0/lapack_lite.so ld: cannot open crtbeginS.o: No such file or directory [root@harmony LALITE]# But I don't know much about g77 (or gcc, for that matter), so I didn't know how to diagnose the error. I'm also not sure I'd know what to do next if the link step had worked! I'd sure appreciate some help with this... Thanks! David "Scott M. Ransom" wrote:
Frank Horowitz wrote:
However, when I coerced the distutils system to get around that bug (by specifying "/usr/lib " with a trailing blank for the BLASLIBDIR and LAPACKLIBDIR variables in setup.py) the same problem (i.e. an "ImportError: /usr/lib/liblapack.so.3: undefined symbol: e_wsfe" in importing lapack_lite) ultimately manifested itself.
This problem is easily fixed (at least on linux) by performing the link of lapack_lite.so with g77 instead of gcc (this is required because the lapack and/or blas libraries are based on fortran object files...).
For instance the out-of-box link command on my machine (Debian 2.2) is:
gcc -shared build/temp.linux2/Src/lapack_litemodule.o -L/usr/local/lib -L/usr/lib -llapack -lblas -o build/lib.linux2/lapack_lite.so
Simply change the 'gcc' to 'g77' and everything works nicely.
Not sure if this is specific to Linux or not...
Scott
-- Scott M. Ransom Address: Harvard-Smithsonian CfA Phone: (617) 495-4142 60 Garden St. MS 10 email: ransom@cfa.harvard.edu Cambridge, MA 02138 GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
participants (4)
-
David H. Marimont -
Frank Horowitz -
Robert Kern -
Scott M. Ransom