[csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
pfelecan at opencsw.org
Fri Aug 9 09:37:16 CEST 2013
As discussed previously, most of the 2.6 modules can be interpreted
by a 2.7 Python. However, it was raised as a strong conjecture
that for binary modules there are issues.
Working on a 2.7 project, I'm encountering a situation when there
is just this kind of incompatibility. For the sake of other
maintainer stumbling on this and to stimulate a discussion for a
resolution strategy, here is a description.
The symptom is the message:
Fatal Python error: Interpreter not initialized (version mismatch?)
Abort - core dumped
Trussing the Python interpreter shows that:
- it tries to load the lxml module in the 2.7 tree:
stat64("/opt/csw/lib/python2.7/lxml", 0x08044A70) Err#2 ENOENT
open64("/opt/csw/lib/python2.7/lxml.so", O_RDONLY) Err#2 ENOENT
- there is no 2.7 module, consequently we en searching the "global"
directory, where it is found:
stat64("/opt/csw/lib/python/site-packages/lxml", 0x08044A70) = 0
- this module provides a shared object etree.so which is loaded:
resolvepath("/opt/csw/lib/python/site-packages/lxml/etree.so", "/opt/csw/lib/python/site-packages/lxml/etree.so", 1023) = 47
open("/opt/csw/lib/python/site-packages/lxml/etree.so", O_RDONLY) = 9
- this shared object is linked, nominally, with the Python 2.6
libxslt.so.1 => /opt/csw/lib/i386/libxslt.so.1
libexslt.so.0 => /opt/csw/lib/i386/libexslt.so.0
libxml2.so.2 => /opt/csw/lib/i386/libxml2.so.2
libpython2.6.so.1.0 => /opt/csw/lib/i386/libpython2.6.so.1.0
stat64("/opt/csw/lib/i386/libpython2.6.so.1.0", 0x08044020) = 0
resolvepath("/opt/csw/lib/i386/libpython2.6.so.1.0", "/opt/csw/lib/libpython2.6.so.1.0", 1023) = 32
open("/opt/csw/lib/i386/libpython2.6.so.1.0", O_RDONLY) = 9
- the symptom is revealed an we get a nice core dump.
- the error happens in Python/modsupport.c, line 37 and following:
Py_FatalError("Interpreter not initialized (version mismatch?)");
which is to be expected.
What's the solution for this issue? The obvious answer is to
provide a specific module for each version with a shared object
linked with the corresponding Python library.
I'm trying to build the lxml module using the new multi version
modules provided by Maciej.
Unfortunately it's not a pleasure ride... I'm trying to demangle
this and will give a status in a follow up.
More information about the maintainers