Summary: | Python 2.4 builds okay on 2004.3 based x86 hardened system, but cPickle.so module fails to import with unknown symbol. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Heiko Wundram <modelnine> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED INVALID | ||
Severity: | blocker | CC: | hardened |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 79877 |
Description
Heiko Wundram
2005-03-28 02:02:39 UTC
I'll have console access to the machine in question tomorrow; this means that I'll have a closer look at why loading cPickle.so fails then. If this turns out to be a hardened problem, I'd propose to remove the block for bug 79877... Please use the 2005.0 hardened stages on from your local mirror. I'm trying to mark this bug as invalid (but I can't login to my account from univ), as I found another Python 2.4 to be installed in /usr/local, which was causing this bug. The Python in /usr/local seems to have been built by another admin, and was compiled using UCS2, which means that python2.4 (the executable) was using a library version which was incompatible with UCS4 (and thus incompatible with the dynamic libs of Gentoo Python). It just seems strange that /usr/local/lib comes before /usr/lib on the search path, as ldconfig also displayed /usr/lib/libpython2.4.so.1.0 as the dynamic library to be used by ld.so, whereas the dynamic library from /usr/local wasn't using /usr/local/lib/python2.4 as the library search path, but /usr/lib/python2.4. Well, anyway, the bug's gone by removing all python2.4 related stuff from /usr/local, so please somebody mark this as invalid and remove the blocker for bug 79877. Thanks Heiko, closing as Invalid. |