I am really sorry to be landing on the mailing list with Atlas build issues. I usually manage be myself to build Atlas, but this time I have been fighting for a couple of days with little success. The reason I need to build Atlas is that our work computers are stuck on Mandriva 2008.0, in which the version of Atlas packaged by the system is not usable. Anyhow, I lost quite a while with Atlas 3.9.26, for which I was never able to build libaries that could be used in a '.so' (seemed that the -fPIC was not working, but really I don't understand what was going on in the maze of makefiles). After that I switched to 3.9;25, which I have already have gotten working on another system (Mandriva 2008, but 32 bits). Know everything builds, but I get a missing symbol at the import: from numpy.linalg import lapack_lite ImportError: /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: undefined symbol: zgesdd_ I don't have g77 installed on the system at all, to avoid gfortran/g77 mixups. I am attaching the stout of 'python setup.py build_ext -i', in case it contains useful information. Would anybody have suggestions with regards to what I am doing wrong? Cheers, Ga�l
On 10/20/2010 10:23 AM, Gael Varoquaux wrote:
I am really sorry to be landing on the mailing list with Atlas build issues. I usually manage be myself to build Atlas, but this time I have been fighting for a couple of days with little success.
The reason I need to build Atlas is that our work computers are stuck on Mandriva 2008.0, in which the version of Atlas packaged by the system is not usable.
Anyhow, I lost quite a while with Atlas 3.9.26, for which I was never able to build libaries that could be used in a '.so' (seemed that the -fPIC was not working, but really I don't understand what was going on in the maze of makefiles). After that I switched to 3.9;25, which I have already have gotten working on another system (Mandriva 2008, but 32 bits). Know everything builds, but I get a missing symbol at the import:
from numpy.linalg import lapack_lite ImportError: /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: undefined symbol: zgesdd_
I don't have g77 installed on the system at all, to avoid gfortran/g77 mixups.
I am attaching the stout of 'python setup.py build_ext -i', in case it contains useful information.
Would anybody have suggestions with regards to what I am doing wrong?
I could not read the stdout but perhaps you didn't build atlas with complete lapack. The basic steps for that are described in http://math-atlas.sourceforge.net/errata.html#completelp HTH, Pearu
On Wed, Oct 20, 2010 at 10:32:48AM +0300, Pearu Peterson wrote:
I could not read the stdout
Because I forgot to attach it! I added it
but perhaps you didn't build atlas with complete lapack.
That's quite possible. The size of liblapack.a seems a bit too small (1.1M). On the system for which it works, I have 8M.
The basic steps for that are described in http://math-atlas.sourceforge.net/errata.html#completelp
Hum, this page is mentionning a '--with-netlib-lapack' swith the the configre that is not in the INSTALL.txt of my atlas version. I was using the '-Ss flapack' switch. I'll investigate that. Thanks a lot for the pointer, Gaël
On Wed, Oct 20, 2010 at 09:38:25AM +0200, Gael Varoquaux wrote:
Hum, this page is mentionning a '--with-netlib-lapack' swith the the configre that is not in the INSTALL.txt of my atlas version.
OK, that's no longer valid. However, I just realize that atlas now packages the netlib lapack in the source. I am wondering if the switch that I was giving to point to the lapack sources it was not confusing the build process. I am retrying without that switch. Gaël
On Wed, Oct 20, 2010 at 09:43:12AM +0200, Gael Varoquaux wrote:
On Wed, Oct 20, 2010 at 09:38:25AM +0200, Gael Varoquaux wrote:
Hum, this page is mentionning a '--with-netlib-lapack' swith the the configre that is not in the INSTALL.txt of my atlas version.
OK, that's no longer valid.
However, I just realize that atlas now packages the netlib lapack in the source. I am wondering if the switch that I was giving to point to the lapack sources it was not confusing the build process. I am retrying without that switch.
No progress. Same problem.
On 10/20/2010 04:23 PM, Gael Varoquaux wrote:
I am really sorry to be landing on the mailing list with Atlas build issues. I usually manage be myself to build Atlas, but this time I have been fighting for a couple of days with little success.
The reason I need to build Atlas is that our work computers are stuck on Mandriva 2008.0, in which the version of Atlas packaged by the system is not usable.
Anyhow, I lost quite a while with Atlas 3.9.26, for which I was never able to build libaries that could be used in a '.so' (seemed that the -fPIC was not working, but really I don't understand what was going on in the maze of makefiles). After that I switched to 3.9;25, which I have already have gotten working on another system (Mandriva 2008, but 32 bits). Know everything builds, but I get a missing symbol at the import:
from numpy.linalg import lapack_lite ImportError: /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: undefined symbol: zgesdd_
The two first things to check in those cases (atlas or not): - ldd /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: does it load the libraries you think are you loading ? - nm atlas_libraries | grep zgesdd_ for every library in atlas (I don't know how the recent ones work, but this function should normally be in libf77blas.so) The way to get -fPIC everywhere used to be -Fa alg -fPIC during configure, but that may have changed. David
On 10/20/2010 04:39 PM, David wrote:
On 10/20/2010 04:23 PM, Gael Varoquaux wrote:
I am really sorry to be landing on the mailing list with Atlas build issues. I usually manage be myself to build Atlas, but this time I have been fighting for a couple of days with little success.
The reason I need to build Atlas is that our work computers are stuck on Mandriva 2008.0, in which the version of Atlas packaged by the system is not usable.
Anyhow, I lost quite a while with Atlas 3.9.26, for which I was never able to build libaries that could be used in a '.so' (seemed that the -fPIC was not working, but really I don't understand what was going on in the maze of makefiles). After that I switched to 3.9;25, which I have already have gotten working on another system (Mandriva 2008, but 32 bits). Know everything builds, but I get a missing symbol at the import:
from numpy.linalg import lapack_lite ImportError: /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: undefined symbol: zgesdd_
The two first things to check in those cases (atlas or not):
- ldd /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: does it load the libraries you think are you loading ? - nm atlas_libraries | grep zgesdd_ for every library in atlas (I don't know how the recent ones work, but this function should normally be in libf77blas.so)
Sorry, it should be in lapack, not the f77 blas wrapper, David
On Wed, Oct 20, 2010 at 04:41:38PM +0900, David wrote:
- ldd /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: does it load the libraries you think are you loading ?
For the dynamic libraries, it seems so. I am using static libraries for atlas/blas (.a)
- nm atlas_libraries | grep zgesdd_ for every library in atlas (I don't know how the recent ones work, but this function should normally be in libf77blas.so)
Nothing. That's clearly my problem, but I don't know how to fix it. Thanks for your suggestions, G
On 10/20/2010 11:48 AM, Gael Varoquaux wrote:
On Wed, Oct 20, 2010 at 04:41:38PM +0900, David wrote:
- ldd /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: does it load the libraries you think are you loading ?
For the dynamic libraries, it seems so. I am using static libraries for atlas/blas (.a)
- nm atlas_libraries | grep zgesdd_ for every library in atlas (I don't know how the recent ones work, but this function should normally be in libf77blas.so)
Hmm, zgesdd.f is part of LAPACK, why the function should be in BLAS library..
Nothing. That's clearly my problem, but I don't know how to fix it.
Thanks for your suggestions,
I haven't build atlas libraries for awhile and may be something is changed in atlas.. That said, I would try instructions from http://www.scipy.org/Installing_SciPy/Linux#head-89e1f6afaa3314d98a22c79b063... and may be using some older atlas version. Pearu
On Wed, Oct 20, 2010 at 11:59:24AM +0300, Pearu Peterson wrote:
I haven't build atlas libraries for awhile and may be something is changed in atlas.. That said, I would try instructions from
http://www.scipy.org/Installing_SciPy/Linux#head-89e1f6afaa3314d98a22c79b063...
That was my first try
and may be using some older atlas version.
I can do it with older versions, but I get a segfault in an SVD that I really need to do. This is actually what started the current endeaviour. Maybe I should bisect to try and find a version where the SVD does not segfault, and that I can build and link. That seems like a lot of work. :( Gaël
--with-netlib-lapack is indeed no longer valid. INSTALL.txt includes a warning that INSTALL.txt is out of date, you should refer to doc/atlas_install.pdf instead. The new option is --with-netlib-lapack-tarfile I successfully built 3.9.25 with this option a while ago, but haven't been able to get numpy to use it. On Wed, Oct 20, 2010 at 5:01 AM, Gael Varoquaux < gael.varoquaux@normalesup.org> wrote:
On Wed, Oct 20, 2010 at 11:59:24AM +0300, Pearu Peterson wrote:
I haven't build atlas libraries for awhile and may be something is changed in atlas.. That said, I would try instructions from
http://www.scipy.org/Installing_SciPy/Linux#head-89e1f6afaa3314d98a22c79b063...
That was my first try
and may be using some older atlas version.
I can do it with older versions, but I get a segfault in an SVD that I really need to do. This is actually what started the current endeaviour.
Maybe I should bisect to try and find a version where the SVD does not segfault, and that I can build and link. That seems like a lot of work.
:(
Gaël _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Oct 20, 2010 at 09:13:24AM -0400, Ian Goodfellow wrote:
--with-netlib-lapack is indeed no longer valid. INSTALL.txt includes a warning that INSTALL.txt is out of date, you should refer to doc/atlas_install.pdf instead.
Ah, I read too quickly and missed that. Thanks.
The new option is --with-netlib-lapack-tarfile I successfully built 3.9.25 with this option a while ago, but haven't been able to get numpy to use it.
Do you remember what the issue was? Ga�l
There were two problems. First, numpy ignored my export ATLAS=/usr/local/atlas. setup.py printed out the directories it was searching and it just searched the defaults then said it couldn't find ATLAS. I 'fixed' that problem by adding symlinks in the default directories. Now I get error messages like these in the output of setup.py: C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.6 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function ‘exp’ gcc -pthread _configtest.o -o _configtest _configtest.o: In function `main': /home/ia3n/Libraries/numpy/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status _configtest.o: In function `main': /home/ia3n/Libraries/numpy/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status failure. On Wed, Oct 20, 2010 at 9:29 AM, Gael Varoquaux < gael.varoquaux@normalesup.org> wrote:
On Wed, Oct 20, 2010 at 09:13:24AM -0400, Ian Goodfellow wrote:
--with-netlib-lapack is indeed no longer valid. INSTALL.txt includes a warning that INSTALL.txt is out of date, you should refer to doc/atlas_install.pdf instead.
Ah, I read too quickly and missed that. Thanks.
The new option is --with-netlib-lapack-tarfile I successfully built 3.9.25 with this option a while ago, but haven't been able to get numpy to use it.
Do you remember what the issue was?
Gaël
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
participants (4)
-
David -
Gael Varoquaux -
Ian Goodfellow -
Pearu Peterson