Peter FELECAN <pfele...@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
_______________________________________________
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.
