From: Karol L. <kar...@kn...> - 2006-10-07 12:14:01
|
Dear list, I'm trying to compile ATLAS 3.6.0 and LAPACK 3.0 (+ update) and use them with the latest numpy (checked out today). Installation seems to be fine, all the libraries are detected. When I import numpy, however, I get this: Python 2.5 (r25:51908, Sep 27 2006, 17:40:29) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/langner/apps/python/lib/python2.5/site-packages/numpy/__init__.py", line 40, in <module> import linalg File "/home/langner/apps/python/lib/python2.5/site-packages/numpy/linalg/__init__.py", line 4, in <module> from linalg import * File "/home/langner/apps/python/lib/python2.5/site-packages/numpy/linalg/linalg.py", line 25, in <module> from numpy.linalg import lapack_lite ImportError: /home/langner/apps/python/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so: undefined symbol: xerbla_ Does anyone know where this comes from? Cheers, Karol -- written by Karol Langner Sat Oct 7 14:02:46 CEST 2006 |
From: Albert S. <fu...@gm...> - 2006-10-07 12:20:07
|
Hello all > -----Original Message----- > From: num...@li... [mailto:numpy- > dis...@li...] On Behalf Of Karol Langner > Sent: 07 October 2006 14:07 > To: NumPy List > Subject: [Numpy-discussion] problem with lapack_lite / BLAS > > Dear list, > > I'm trying to compile ATLAS 3.6.0 and LAPACK 3.0 (+ update) and use them > with > the latest numpy (checked out today). Installation seems to be fine, all > the > libraries are detected. When I import numpy, however, I get this: > > <snip> > ImportError: /home/langner/apps/python/lib/python2.5/site- > packages/numpy/linalg/lapack_lite.so: > undefined symbol: xerbla_ > > Does anyone know where this comes from? xerbla is an error handler for the LAPACK routines. Make sure you included xerbla.f when building your LAPACK library. Check the symbols included in the library with strings or objdump. Hope this helps. Cheers, Albert |
From: Karol L. <kar...@kn...> - 2006-10-07 13:00:32
|
On Saturday 07 of October 2006 14:20, Albert Strasheim wrote: > Hello all > > > -----Original Message----- > > From: num...@li... [mailto:numpy- > > dis...@li...] On Behalf Of Karol Langner > > Sent: 07 October 2006 14:07 > > To: NumPy List > > Subject: [Numpy-discussion] problem with lapack_lite / BLAS > > > > Dear list, > > > > I'm trying to compile ATLAS 3.6.0 and LAPACK 3.0 (+ update) and use them > > with > > the latest numpy (checked out today). Installation seems to be fine, all > > the > > libraries are detected. When I import numpy, however, I get this: > > > > <snip> > > ImportError: /home/langner/apps/python/lib/python2.5/site- > > packages/numpy/linalg/lapack_lite.so: > > undefined symbol: xerbla_ > > > > Does anyone know where this comes from? > > xerbla is an error handler for the LAPACK routines. Make sure you included > xerbla.f when building your LAPACK library. Check the symbols included in > the library with strings or objdump. > > Hope this helps. > > Cheers, > > Albert Yes, I know, and I checked this, and xerbla.o is in my lapack library, ad provides "xerbla_": langner@~/apps/linalg/lib: objdump -x liblapack.a | grep "xerbla.o" -A 100 xerbla.o: file format elf32-i386 rw-r--r-- 1000/1000 1380 Oct 6 17:51 2006 xerbla.o architecture: i386, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x00000000 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000061 00000000 00000000 00000040 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 0000006a 00000000 00000000 000000c0 2**5 CONTENTS, ALLOC, LOAD, RELOC, DATA 2 .bss 00000000 00000000 00000000 0000012c 2**2 ALLOC 3 .rodata 00000000 00000000 00000000 0000012c 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .rodata.cst4 00000004 00000000 00000000 0000012c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .note.GNU-stack 00000000 00000000 00000000 00000130 2**0 CONTENTS, READONLY 6 .comment 00000026 00000000 00000000 00000130 2**0 CONTENTS, READONLY SYMBOL TABLE: 00000000 l df *ABS* 00000000 xerbla.f 00000000 l d .text 00000000 00000000 l d .data 00000000 00000000 l d .bss 00000000 00000000 l O .data 00000014 __g77_cilist_0.1 00000020 l O .data 0000004a __g77_format_9999.0 00000000 l d .rodata 00000000 00000000 l d .rodata.cst4 00000000 00000000 l d .note.GNU-stack 00000000 00000000 l d .comment 00000000 00000000 g F .text 00000061 xerbla_ 00000000 *UND* 00000000 s_wsfe 00000000 *UND* 00000000 do_fio 00000000 *UND* 00000000 e_wsfe 00000000 *UND* 00000000 s_stop RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE (...) And this _is_ the library I point to in site.cfg. Karol -- written by Karol Langner Sat Oct 7 14:53:15 CEST 2006 |
From: Karol L. <kar...@kn...> - 2006-10-07 18:02:15
|
On Saturday 07 of October 2006 15:00, Karol Langner wrote: > > > From: num...@li... [mailto:numpy- > > > dis...@li...] On Behalf Of Karol Langner > > > Sent: 07 October 2006 14:07 > > > To: NumPy List > > > Subject: [Numpy-discussion] problem with lapack_lite / BLAS > > > > > > Dear list, > > > > > > I'm trying to compile ATLAS 3.6.0 and LAPACK 3.0 (+ update) and use > > > them with > > > the latest numpy (checked out today). Installation seems to be fine, > > > all the > > > libraries are detected. When I import numpy, however, I get this: > > > > > > <snip> > > > ImportError: /home/langner/apps/python/lib/python2.5/site- > > > packages/numpy/linalg/lapack_lite.so: > > > undefined symbol: xerbla_ > > > > > > Does anyone know where this comes from? OK... I am so angry at myself... I spent around 2 hours fiddling around with blas/lapack and numpy, and the problem was that I wasn't removing the 'build' directory between compiilations. Apparently it's not enough to run "setup.py clean" (I read this and forgot about it) to recompile lapack_lite.so. Now numpy imports fine and everything I use it for works as before (only a bit faster). Karol P.S. I still get a floating point exception when running the numpy tests, though. I haven't checked out numpy for some time, so I don't now if it's a bug, or if it's my setup. The same thing happens when I use my manually built atlas/lapack and the built-in debian atlas/lapack libraries. I'd be grateful for a comment on if this is just me: >>numpy.test(10,10) [output] Check reading the top fields of a nested array ... ok Check reading the nested fields of a nested array (1st level) ... ok Check access nested descriptors of a nested array (1st level) ... ok Check reading the nested fields of a nested array (2nd level) ... ok Check access nested descriptors of a nested array (2nd level) ... ok check_access_fields (numpy.core.tests.test_numerictypes.test_read_values_plain_multiple) ... ok check_access_fields (numpy.core.tests.test_numerictypes.test_read_values_plain_single) ... ok check_cdouble (numpy.tests.test_linalg.test_det)Floating point exception thanks! -- written by Karol Langner Sat Oct 7 19:41:58 CEST 2006 |
From: Pauli V. <pa...@ik...> - 2006-10-07 18:32:36
|
la, 2006-10-07 kello 20:01 +0200, Karol Langner kirjoitti: > I still get a floating point exception when running the numpy tests, though. I > haven't checked out numpy for some time, so I don't now if it's a bug, or if > it's my setup. The same thing happens when I use my manually built > atlas/lapack and the built-in debian atlas/lapack libraries. I'd be grateful > for a comment on if this is just me: > > >>numpy.test(10,10) > [output] > Check reading the top fields of a nested array ... ok > Check reading the nested fields of a nested array (1st level) ... ok > Check access nested descriptors of a nested array (1st level) ... ok > Check reading the nested fields of a nested array (2nd level) ... ok > Check access nested descriptors of a nested array (2nd level) ... ok > check_access_fields > (numpy.core.tests.test_numerictypes.test_read_values_plain_multiple) ... ok > check_access_fields > (numpy.core.tests.test_numerictypes.test_read_values_plain_single) ... ok > check_cdouble (numpy.tests.test_linalg.test_det)Floating point exception If you are using Debian stable (sarge), you might need to read http://www.its.caltech.edu/~astraw/coding.html#libc-patched-for-debian-sarge-to-fix-floating-point-exceptions-on-sse2 In short, libc in Debian stable has a bug that makes programs crash with SIGFPE when SSE instructions are invoked. The solution is to recompile libc from patched sources, and replace libm.so.6. At least for me this fixed crashes in numpy. Pauli Virtanen |
From: Karol L. <kar...@kn...> - 2006-10-10 06:12:06
|
On Saturday 07 of October 2006 20:32, Pauli Virtanen wrote: > la, 2006-10-07 kello 20:01 +0200, Karol Langner kirjoitti: > > I still get a floating point exception when running the numpy tests, > > though. I haven't checked out numpy for some time, so I don't now if it's > > a bug, or if it's my setup. The same thing happens when I use my manually > > built atlas/lapack and the built-in debian atlas/lapack libraries. I'd be > > grateful > > > > for a comment on if this is just me: > > >>numpy.test(10,10) > > > > [output] > > Check reading the top fields of a nested array ... ok > > Check reading the nested fields of a nested array (1st level) ... ok > > Check access nested descriptors of a nested array (1st level) ... ok > > Check reading the nested fields of a nested array (2nd level) ... ok > > Check access nested descriptors of a nested array (2nd level) ... ok > > check_access_fields > > (numpy.core.tests.test_numerictypes.test_read_values_plain_multiple) ... > > ok check_access_fields > > (numpy.core.tests.test_numerictypes.test_read_values_plain_single) ... ok > > check_cdouble (numpy.tests.test_linalg.test_det)Floating point exception > > If you are using Debian stable (sarge), you might need to read > > http://www.its.caltech.edu/~astraw/coding.html#libc-patched-for-debian-sarg >e-to-fix-floating-point-exceptions-on-sse2 > > In short, libc in Debian stable has a bug that makes programs crash with > SIGFPE when SSE instructions are invoked. The solution is to recompile > libc from patched sources, and replace libm.so.6. At least for me this > fixed crashes in numpy. > > Pauli Virtanen Big thanks for that link. I took the leap and it does fix that SIGFPE. As a note, after building the glibc sources, you only have to install the libc6 binary deb. There should be a link to that page somewhere on the wiki. Karol -- written by Karol Langner Tue Oct 10 08:07:04 CEST 2006 |