Bug 478435
Summary: | ndimage.histogram is broken for Fedora 9 and 10 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | vossman <vossman77> |
Component: | scipy | Assignee: | Jef Spaleta <jspaleta> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 10 | CC: | jonathansteffan, jspaleta, jss |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 0.7.0-0.1.b1.fc10 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-02-24 20:59:32 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
vossman
2008-12-30 01:54:44 UTC
I poked at this a little bit. I can reproduce it on my x86 laptop. The problem is definitely in C code associated with the compiled _ndimage.so file. So what system libraries does this compiled .so file depend on? ldd /usr/lib/python2.5/site-packages/scipy/ndimage/_nd_image.so linux-gate.so.1 => (0x00110000) libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0x0012e000) libpthread.so.0 => /lib/libpthread.so.0 (0x0027f000) libc.so.6 => /lib/libc.so.6 (0x00299000) libdl.so.2 => /lib/libdl.so.2 (0x0040d000) libutil.so.1 => /lib/libutil.so.1 (0x00412000) libm.so.6 => /lib/libm.so.6 (0x00416000) /lib/ld-linux.so.2 (0x00892000) These are all pretty mundane... no atlas are anything like that. It depends on libpython and a smattering of libraries in the glibc package. Is this subtle python 2.5 api breakage? I don't know. rhel5 is using python2.4. I'm assuming f8 is a well. I'll jump on the upstream bug report and try to help narrow it down. -jef Okay I have scratch builds of scipy v0.7b1 available in koji for F10 http://koji.fedoraproject.org/koji/taskinfo?taskID=1028262 Can you do a quick test of the packages for the arches you have available for F10. I installed the x86 package and I no longer get the illegal instruction error. -jef Thanks and good detective work. I tried it on 2 Fedora 10 x86_64 machines and 1 Fedora 9 i686 machine and the ndimage test worked on all 3 machines.
But I can no longer import scipy.stats, I get the error:
>>> import scipy.stats
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.5/site-packages/scipy/stats/__init__.py", line 7, in <module>
from stats import *
File "/usr/lib64/python2.5/site-packages/scipy/stats/stats.py", line 199, in <module>
import scipy.linalg as linalg
File "/usr/lib64/python2.5/site-packages/scipy/linalg/__init__.py", line 8, in <module>
from basic import *
File "/usr/lib64/python2.5/site-packages/scipy/linalg/basic.py", line 17, in <module>
from lapack import get_lapack_funcs
File "/usr/lib64/python2.5/site-packages/scipy/linalg/lapack.py", line 18, in <module>
from scipy.linalg import clapack
ImportError: /usr/lib64/python2.5/site-packages/scipy/linalg/clapack.so: undefined symbol: clapack_sgesv
Im not getting that import error on my F10 x86 system. Did you get that scipy.stat import error on the F9 or F10 system? The build I posted was only meant for F10. I have no idea if it would work on F9. I might try patching the 0.6 scipy with the ndimage src from the 0.7b1. I'm wary about dropping in an 0.7 beta as an update...introducing a lot of new issues. -jef I get the error on all 3 of the machines mentioned, both F10 and F9. Hmm, this is weird. Anything else I can do to test this? stats: ----- python v 2.5.2 (r252:60911, Sep 30 2008, 15:42:03) [GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] numpy v 1.2.0 scipy v 0.7.0b1 and import scipy.stats worked for you in scipy 0.6? okay back to the segfault... undefined symbol: clapack_sgesv clapack_sgesv should be defined as a symbol from the lapack library provided by the atlas package. Here's the analysis: nm -D /usr/lib/python2.5/site-packages/scipy/linalg/clapack.so |grep clapack_sgesv U clapack_sgesv ldd /usr/lib/python2.5/site-packages/scipy/linalg/clapack.so linux-gate.so.1 => (0x00110000) liblapack.so.3 => /usr/lib/atlas/liblapack.so.3 (0x0012a000) libf77blas.so.3 => /usr/lib/atlas/libf77blas.so.3 (0x00666000) libcblas.so.3 => /usr/lib/atlas/libcblas.so.3 (0x00682000) libatlas.so.3 => /usr/lib/atlas/libatlas.so.3 (0x008b5000) libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0x006a2000) libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00bf7000) libm.so.6 => /lib/libm.so.6 (0x007f3000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0081c000) libc.so.6 => /lib/libc.so.6 (0x00cb1000) libblas.so.3 => /usr/lib/atlas/libblas.so.3 (0x00e25000) libpthread.so.0 => /lib/libpthread.so.0 (0x0082a000) libdl.so.2 => /lib/libdl.so.2 (0x00844000) libutil.so.1 => /lib/libutil.so.1 (0x00849000) /lib/ld-linux.so.2 (0x00892000) nm -D /usr/lib/atlas/liblapack.so.3 | grep clapack_sgesv 000cffc0 T clapack_sgesv rpm -qf /usr/lib/atlas/liblapack.so.3 atlas-3.6.0-15.fc10.i386 Run a similar analysis on your affected machine with scipy v0.7b1 installed. Does the liblapack.so.3 library exist and does it provide the missing symbol? -jef Yes, it worked on all versions. I am trying to get my program to run on F9/F10 machines. If I replace your clapack.so with a clapack.so that I compiled it works fine. Analysis below with lib64 instead of lib ========================= % nm -D /usr/lib64/python2.5/site-packages/scipy/linalg/clapack.so |grep clapack_sges U clapack_sgesv % ldd /usr/lib64/python2.5/site-packages/scipy/linalg/clapack.so linux-vdso.so.1 => (0x00007fff281fd000) liblapack.so.3 => /usr/lib64/liblapack.so.3 (0x000000000032d000) libf77blas.so.3 => /usr/lib64/atlas/libf77blas.so.3 (0x0000000000abf000) libcblas.so.3 => /usr/lib64/atlas/libcblas.so.3 (0x0000000000cdc000) libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x0000000000ef9000) libpython2.5.so.1.0 => /usr/lib64/libpython2.5.so.1.0 (0x0000000046293000) libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x0000000001879000) libm.so.6 => /lib64/libm.so.6 (0x0000000001b53000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000000001dd8000) libc.so.6 => /lib64/libc.so.6 (0x0000000001fef000) libblas.so.3 => /usr/lib64/libblas.so.3 (0x0000000002361000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000000025b9000) libdl.so.2 => /lib64/libdl.so.2 (0x00000000027d5000) libutil.so.1 => /lib64/libutil.so.1 (0x00000000029d9000) /lib64/ld-linux-x86-64.so.2 (0x0000003647400000) % nm -D /usr/lib64/atlas/liblapack.so.3 | grep clapack_sgesv 00000000000da7cc T clapack_sgesv % rpm -qf /usr/lib64/atlas/liblapack.so.3 atlas-3.6.0-15.fc10.x86_64 % python -c 'import scipy.stats' Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib64/python2.5/site-packages/scipy/stats/__init__.py", line 7, in <module> from stats import * File "/usr/lib64/python2.5/site-packages/scipy/stats/stats.py", line 199, in <module> import scipy.linalg as linalg File "/usr/lib64/python2.5/site-packages/scipy/linalg/__init__.py", line 8, in <module> from basic import * File "/usr/lib64/python2.5/site-packages/scipy/linalg/basic.py", line 17, in <module> from lapack import get_lapack_funcs File "/usr/lib64/python2.5/site-packages/scipy/linalg/lapack.py", line 18, in <module> from scipy.linalg import clapack ImportError: /usr/lib64/python2.5/site-packages/scipy/linalg/clapack.so: undefined symbol: clapack_sgesv Downloading the build and doing the follow successfully imports for me: $ sudo yum localinstall scipy-0.7.0-0.2.b1.fc10.x86_64.rpm [..] Installed: scipy.x86_64 0:0.7.0-0.2.b1.fc10 Dependency Installed: atlas.x86_64 0:3.6.0-15.fc10 libgfortran.x86_64 0:4.3.2-7 numpy.x86_64 0:1.2.0-1.fc10 python-nose.noarch 0:0.10.3-1.fc10 python-setuptools.noarch 0:0.6c9-1.fc10 suitesparse.x86_64 0:3.1.0-1.fc9 $ python Python 2.5.2 (r252:60911, Sep 30 2008, 15:42:03) [GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.stats /usr/lib64/python2.5/site-packages/scipy/sparse/linalg/dsolve/linsolve.py:20: DeprecationWarning: scipy.sparse.linalg.dsolve.umfpack will be removed, install scikits.umfpack instead ' install scikits.umfpack instead', DeprecationWarning ) >>> print scipy.stats.__doc__ Statistical Functions ===================== [...] >>> $ uname -a Linux dabeatport 2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64 x86_64 GNU/Linux $ rpm -q python python-2.5.2-1.fc10.x86_64 vossman, Your clapack.so issue is a bit bizarre in that I can not get it confirmed by others. I'm going to release scipy v0.7 beta to updates-testing for f9 and f10. But I'm still not convinced that I should push these beta as an actual update. I want this tested significantly. I am a little concerned about your clapack.so issue, if you are able, please can you retest this scipy v0.7 on a fresh f10 install with official fedora updates before any other local customizations are applied. My gut tells me that you've got some local environment interactions going that we aren't going to be able to reproduce on a stock f10+updates setup. But I need you to try to confirm that. -jef scipy-0.7.0-0.1.b1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/scipy-0.7.0-0.1.b1.fc9 scipy-0.7.0-0.1.b1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/scipy-0.7.0-0.1.b1.fc10 I tried this on my home machine, Core 2 Duo with F10 and I get a warning, which is what you get:
after running:
% sudo rpm -Uhv scipy-0.7.0-0.2.b1.fc10.x86_64.rpm
% python
>>> import scipy.stats
/usr/lib64/python2.5/site-packages/scipy/sparse/linalg/dsolve/linsolve.py:20: DeprecationWarning: scipy.sparse.linalg.dsolve.umfpack will be removed, install scikits.umfpack instead
' install scikits.umfpack instead', DeprecationWarning )
First, all my machines as essentially default installs of Fedora 10 and I cannot think any custom packages installed. All run the nvidia drivers from rpmfusion. some have been upgrade from previous Fedora version and one is a brand new install. I run yum update regularly. I have three fedora work machines (x86_64|f10, x86_64|f10, and i686|f9) and two fedora home machines (x86_64|f10 and i686|f8) and access to numerous other CentOS5 machines without root access. In order to test this bug, I downloaded and compiled scipy, myself.
With your RPM on my 3 work machines I get "undefined symbol: clapack_sgesv", but when I replace the 'clapack.so' from the RPM with a 'clapack.so' from my scipy build folder (on work1) I get the 'DeprecationWarning'. On my home machine, I get the 'DeprecationWarning' from the RPM
Linux home 2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Linux work1 2.6.27.7-134.fc10.x86_64 #1 SMP Mon Dec 1 22:21:35 EST 2008 x86_64 x86_64 x86_64 GNU/Linux (updated not rebooted)
Linux work2 2.6.27.5-117.fc10.x86_64 #1 SMP Tue Nov 18 11:58:53 EST 2008 x86_64 x86_64 x86_64 GNU/Linux (updated not rebooted)
home is a Core 2 Duo with F10
work1 is a dual-dual Xeon (4 procs total)
work2 is Core 2 Quad with F10
=====
Okay, so I tried looking closer at the ldd libraries and noticed they are different for different machines:
% for i in `ldd /usr/lib64/python2.5/site-packages/scipy/linalg/clapack.so | cut -c2- | cut -d' ' -f3`; do md5sum $i; done
% rpm -qa | egrep -i "^(atlas|scipy|numpy|gcc|lapack)" | sort
% rpm -q python
home : "DeprecationWarning"
---
54b6ffd90f354a9a8d51514689dfb51c /usr/lib64/atlas/liblapack.so.3
c45fd264d17b355e39f84172ee2fa505 /usr/lib64/atlas/libf77blas.so.3
532cad2d8a3ae5cffed4e9bd7ba3db70 /usr/lib64/atlas/libcblas.so.3
a5f4c5c1a93ad5b6e7a69af4b15d7948 /usr/lib64/atlas/libatlas.so.3
3853f4938c68adb673930bec1a31265e /usr/lib64/libpython2.5.so.1.0
90d17d13bfca792e45e54287db6b06c1 /usr/lib64/libgfortran.so.3
918476aee51d425111e25f9f7cbbc2dc /lib64/libm.so.6
be75513c367a661b1e925d3c1fb51508 /lib64/libgcc_s.so.1
523ea28facc1c27b13b62cdd6434e399 /lib64/libc.so.6
e36b35a26789539d73597f8b46dd5b07 /usr/lib64/atlas/libblas.so.3
7b8e59087c7a84f17c9861ec1a586042 /lib64/libpthread.so.0
8655decba50ae9838fdb4dca33075927 /lib64/libdl.so.2
2b9d7b735968eefd3c3b2d4d5839b94b /lib64/libutil.so.1
atlas-3.6.0-15.fc10.x86_64
gcc-4.3.2-7.x86_64
gcc-c++-4.3.2-7.x86_64
gcc-gfortran-4.3.2-7.x86_64
gcc-objc-4.3.2-7.x86_64
numpy-1.2.0-1.fc10.x86_64
scipy-0.7.0-0.2.b1.fc10.x86_64
python-2.5.2-1.fc10.x86_64
work1 : "undefined symbol: clapack_sgesv"
-----
330ef08a9077b8db91957a620ff3c2c5 /usr/lib64/liblapack.so.3
c45fd264d17b355e39f84172ee2fa505 /usr/lib64/atlas/libf77blas.so.3
532cad2d8a3ae5cffed4e9bd7ba3db70 /usr/lib64/atlas/libcblas.so.3
a5f4c5c1a93ad5b6e7a69af4b15d7948 /usr/lib64/atlas/libatlas.so.3
a315389ec493c76e7c1db7dd2240921c /usr/lib64/libpython2.5.so.1.0
be75ba75b0c2533717f07a80ad7c63bb /usr/lib64/libgfortran.so.3
0e5ab77488973f46672dcd27f6af8400 /lib64/libm.so.6
46cbc417835df9237d01a547aac19a95 /lib64/libgcc_s.so.1
9eeb7be08e8723346c8ef6f35ad07629 /lib64/libc.so.6
14bbb99e812f6ccaa712d242fcc627fe /usr/lib64/libblas.so.3
b4ff580132d8297070a9e5fb78511f1b /lib64/libpthread.so.0
34be03195b42597b53eca3fc4086f75f /lib64/libdl.so.2
f12b040abe394c200476f065481d5191 /lib64/libutil.so.1
atlas-3.6.0-15.fc10.x86_64
atlas-devel-3.6.0-15.fc10.x86_64
gcc-4.3.2-7.x86_64
gcc-c++-4.3.2-7.x86_64
gcc-gfortran-4.3.2-7.x86_64
gcc-objc-4.3.2-7.x86_64
gcc-objc++-4.3.2-7.x86_64
lapack-3.1.1-4.fc10.x86_64
lapack-devel-3.1.1-4.fc10.x86_64
numpy-1.2.0-1.fc10.x86_64
scipy-0.7.0-0.2.b1.fc10.x86_64
python-2.5.2-1.fc10.x86_64
work2 : "undefined symbol: clapack_sgesv"
-----
330ef08a9077b8db91957a620ff3c2c5 /usr/lib64/liblapack.so.3
c45fd264d17b355e39f84172ee2fa505 /usr/lib64/atlas/libf77blas.so.3
532cad2d8a3ae5cffed4e9bd7ba3db70 /usr/lib64/atlas/libcblas.so.3
a5f4c5c1a93ad5b6e7a69af4b15d7948 /usr/lib64/atlas/libatlas.so.3
e81f1453ef996c9c046b6867c4e5f2a3 /usr/lib64/libpython2.5.so.1.0
774bde26903521befe413d1d4932f568 /usr/lib64/libgfortran.so.3
af821bae00a369c23dac3eca23eb3632 /lib64/libm.so.6
ad6f7620b779ed6c56094d2d5283e9b2 /lib64/libgcc_s.so.1
8ff0d2c0f09a47af17dc46b725621ac2 /lib64/libc.so.6
14bbb99e812f6ccaa712d242fcc627fe /usr/lib64/libblas.so.3
7755c1ef5a1d074002d8cfe351803715 /lib64/libpthread.so.0
5b29d7be530bd7a1f4952c46b33503f9 /lib64/libdl.so.2
e11bf9cabe1b05534cf4e3934de3ecf3 /lib64/libutil.so.1
atlas-3.6.0-15.fc10.x86_64
gcc-4.3.2-7.x86_64
gcc-c++-4.3.2-7.x86_64
gcc-gfortran-4.3.2-7.x86_64
lapack-3.1.1-4.fc10.x86_64
numpy-1.2.0-1.fc10.x86_64
scipy-0.7.0-0.2.b1.fc10.x86_64
python-2.5.2-1.fc10.x86_64
what values should I have, and how did they get different? Shouldn't they be the same for all x86_64 Fedora 10 machines?
Ah i see the problem. atlas and lapack packages both provide the same dynamic library liblapack.so.3 . With lapack package installed its version is found first by the linker instead of the atlas version. Hmm, that's a little unexpected. I can probably work around that in my scipy package, but its probably a more general problem. I need to talk with the atlas and lapack maintainers about what the duplicate library means. stay tuned for another scipy test update. -jef Hmm actually... i still can not reproduce your issue. I have lapack and atlas installed on my f10 system and the atlas libraries are still chosen. You could still be seeing a local environment problem. Do you have some specialized linker path setup in your shell environment which are overriding the defaults? are the variables LD_RUN_PATH or LD_LIBRARY_PATH set in your environment? Did you edit the system linker paths in ld.so.conf or ld.so.conf.d? This could still be a system configuration issue on your machines which is affecting how the linker is operating making it choose the /usr/lib64/liblapack.so.3 over the /usr/lib64/atlas/liblapack.so.3 library by enforcing a different search. -jef Yes, I have customized LD_LIBRARY_PATH, PATH, and PYTHONPATH variables. I added '/usr/lib64/atlas/' to my LD_LIBRARY_PATH and it works fine. While this is a good work-around I think you should definitely contact the the atlas and lapack maintainers about the duplicate libraries. work1 'no warning' ------ 54b6ffd90f354a9a8d51514689dfb51c /usr/lib64/atlas/liblapack.so.3 c45fd264d17b355e39f84172ee2fa505 /usr/lib64/atlas/libf77blas.so.3 532cad2d8a3ae5cffed4e9bd7ba3db70 /usr/lib64/atlas/libcblas.so.3 a5f4c5c1a93ad5b6e7a69af4b15d7948 /usr/lib64/atlas/libatlas.so.3 a315389ec493c76e7c1db7dd2240921c /usr/lib64/libpython2.5.so.1.0 be75ba75b0c2533717f07a80ad7c63bb /usr/lib64/libgfortran.so.3 0e5ab77488973f46672dcd27f6af8400 /lib64/libm.so.6 46cbc417835df9237d01a547aac19a95 /lib64/libgcc_s.so.1 9eeb7be08e8723346c8ef6f35ad07629 /lib64/libc.so.6 a958814cfb895ac1118bd3698a646d25 /usr/lib64/atlas/libblas.so.3 b4ff580132d8297070a9e5fb78511f1b /lib64/libpthread.so.0 34be03195b42597b53eca3fc4086f75f /lib64/libdl.so.2 f12b040abe394c200476f065481d5191 /lib64/libutil.so.1 Okay, thanks for tracking it down and confirming its a linker configuration issue. I've brought this up on the development list. And the follow bug has been filed in response to that discussion. https://bugzilla.redhat.com/show_bug.cgi?id=478856 You should probably add yourself to that bug report, and perhaps explain your work environment needs to the atlas maintainer in an effort to persuade him to change the library name so as to avoid run time linking confusion. FYI, by default with no LD_LIBRARY_PATH environment variable defined.. the atlas package adds the appropriate path definition in a file located in /etc/ld.so.conf.d/ to extend the system wide linker library search path. As do a number of packages. While using LD_LIBRARY_PATH care must be taken as it replaces the system wide search path constructed through /etc/ld.so.conf.d/ Now that this issue is known not to be scipy specific...we can get back to the original problem :-> Please comment on the scipy updates-testing in the bodhi interface as to the suitability of the scipy 0.7 beta release when you are satisfied with your testing. I'm wary of regressions. I'm testing it on my stuff now. -jef Scipy v0.7b passes all my tests, so I placed a comment in bodhi. Thanks for fixing Bug 469392 as well. We wrote a python module called quietscipy to repress all those Deprecation Warnings. Thanks for the '/etc/ld.so.conf.d/' tip I run on a number of machines without root access, so I gone to adjusting my own LD_LIBRARY_PATH. I'll probably go and clean up my machine. scipy-0.7.0-0.1.b1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update scipy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-0020 scipy-0.7.0-0.1.b1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update scipy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-0211 I think we can close this bug. It has been working ever since the update you provided. This still hasn't hit stable updates. I want to keep the bug report open until it hits stable and the bug will autoclose as part of that move. I'm still a little gunshy about pushing a beta release to stable because of potential regressions in other scipy related areas, so the move hasn't happened yet. -jef scipy-0.7.0-0.1.b1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. scipy-0.7.0-0.1.b1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. Hmmm... this update broke my working program. scipy.interpolate.interpolate.interp1d used to return an array as a result if it was passed a single parameter. Now it returns a normal number. I thought I'd add this here to let people know in case it hits someone else. |