[csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules

[Peter FELECAN]

Peter FELECAN <pfelecan at opencsw.org> writes:

> 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.

After solving the gar issues when building multi-versioned Python
modules, I encounter the same symptom as described in the parent
message in /opt/csw/lib/python2.7/distutils/dist.py!

open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Options.so", O_RDONLY) Err#2 ENOENT
open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Optionsmodule.so", O_RDONLY) Err#2 ENOENT
open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Options.py", O_RDONLY) = 6
open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Options.pyc", O_RDONLY) = 7
open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Options.pyc", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0100644) Err#17 EEXIST
open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Scanning.so", O_RDONLY) = 5
open("/opt/csw/lib/python/site-packages/Cython/Compiler/Scanning.so", O_RDONLY) = 6
open("/opt/csw/lib/i386/libpython2.6.so.1.0", O_RDONLY) = 6
    Received signal #6, SIGABRT [default]

That's quite bad and it shows why adding
/opt/csw/lib/python/site-packages at the end of the search path for
Python 2.7 was not a reasonable solution.

I will experiment with a 2.7 Python without this patch which force us to
speed up the delivery of adapted modules. However, this is not a real
issue as we are in "unstable", isn't it?
-- 
Peter