Description of problem: Numpy is unusable in current rawhide. Version-Release number of selected component (if applicable): numpy-1.4.0-1.fc13.x86_64 How reproducible: always Steps to Reproduce: 1. import numpy in a python shell 2. 3. Actual results: [pankaj@localhost Tatu]$ python Python 2.6.4 (r264:75706, Jan 30 2010, 00:24:32) [GCC 4.4.3 20100127 (Red Hat 4.4.3-4)] 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 "/usr/lib64/python2.6/site-packages/numpy/__init__.py", line 132, in <module> import add_newdocs File "/usr/lib64/python2.6/site-packages/numpy/add_newdocs.py", line 9, in <module> from lib import add_newdoc File "/usr/lib64/python2.6/site-packages/numpy/lib/__init__.py", line 13, in <module> from polynomial import * File "/usr/lib64/python2.6/site-packages/numpy/lib/polynomial.py", line 17, in <module> from numpy.linalg import eigvals, lstsq File "/usr/lib64/python2.6/site-packages/numpy/linalg/__init__.py", line 47, in <module> from linalg import * File "/usr/lib64/python2.6/site-packages/numpy/linalg/linalg.py", line 22, in <module> from numpy.linalg import lapack_lite ImportError: /usr/lib64/python2.6/site-packages/numpy/linalg/lapack_lite.so: undefined symbol: zgesdd_ >>> Expected results: numpy shoulb import normally Additional info: googling this says it it due to incompatible lapack versions
*** Bug 560086 has been marked as a duplicate of this bug. ***
I see another liblapack in /usr/lib/atlas of a different version. If I strip the atlas BuildRequires from numpy then the problem goes away, but would re-introduce bug 505376 I guess, but at least numpy would work
Put built without Atlas in rawhide to work around this. I'll play with a permanent fix. Patches welcome.
Building without ATLAS didn't help. See this avogadro build log: http://koji.fedoraproject.org/koji/getfile?taskID=1973177&name=build.log
The catch is that both atlas and lapack provide liblapack.so.3. I assume from the naming that lapack is the canonical one and the one in atlas is intended to be an optimized one or something. The two are incompatible at the moment which is where the problem arises. e.g. bug #478856 If numpy is built *with* atlas available in the buildroot then it ends up requiring libatlas. If it not built with atlas in the buildroot then it doesn't require libatlas. In either case if atlas is installed on the target box then the atlas liblapack overrides the liblapack one and the problem reappears again. With atlas support the problem always happens as atlas must be installed on the target, without atlas support the problem only happens when someone installs atlas. Our atlas is a bit of a mess here. At the least the liblapack in atlas needs to provide zgesdd_, bah.
This is all atlas's fault really, but from the root.log of avogadro I suspect that if there was a Requires: lapack in numpy then the atlas lapack wouldn't be pulled in by koji by the autodependency on liblapack and the build itself would work anyway.
Should I build with that Requires to test?
I reckon its worth a shot. Its only a bandaid over another packages problems, but at least it helps documents that numpy is supposed to be linked to lapack's liblapack.
Done.
But it's likely to break things at runtime for users who have ATLAS installed. We need to get ATLAS fixed. It already includes a bunch of functions from reference LAPACK where it doesn't have an optimized implementation, it just needs to add zgesdd_ to those.
I'll be happy to change it back once atlas is fixed. Should this but perhaps be reassigned to atlas?
Yes, done.
Fixed already.
So can we reenable ATLAS support in numpy now?
*** Bug 565266 has been marked as a duplicate of this bug. ***
*** Bug 565267 has been marked as a duplicate of this bug. ***
Ping, Deji?
(In reply to comment #17) > Ping, Deji? Comment 13
Comment 9
This seems to be fixed in numpy-1.4.0-4.fc13. Wondering, why this bug is still open... Reopen, if I'm wrong...