Bug 562577
Summary: | numpy unusable : ImportError: undefined symbol: zgesdd_ | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | pankaj pandey <pankaj86> |
Component: | numpy | Assignee: | Gwyn Ciesla <gwync> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | caolanm, dakingun, gwync, jeremy, jspaleta, kevin, rdieter, susi.lehtola, tomspur |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | numpy-1.4.0-4.fc13 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-03-10 21:32:59 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: | |||
Bug Depends On: | |||
Bug Blocks: | 539069, 564796, 565086, 565107 |
Description
pankaj pandey
2010-02-07 14:26:43 UTC
*** 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 This seems to be fixed in numpy-1.4.0-4.fc13. Wondering, why this bug is still open... Reopen, if I'm wrong... |