[vtk-developers] Python dll suffix

[David Gobbi]

On Tue, May 8, 2012 at 4:46 AM, Mathieu Malaterre
<mathieu.malaterre at gmail.com> wrote:
>
> Thanks for the clarifications ! However this is still not clear why
> there are still two objects: a shared library and a module. Why can't
> it just be a single module (with the proper file extension for python
> module as explained in your mail) ?

Because the dynamic linker requires the shared library suffix in
order to resolve symbols between the modules at load time.

There are work-arounds.  On Linux, python can be forced to use the
RTLD_GLOBAL flag when loading modules, which eliminates the
need for the "D" libraries but causes other problems.  Another
possibility is to add code to the python module init functions,
to more-or-less duplicate what the run-time linker does.

> Here is my current issue, *PythonD are not quite shared libs
> (soname+soversion), since there ABI is mostly X.Y (vtk SOVERSION) +
> Z.T (pythonZ.T version) and not just X.Y. What this means is that when
> doing a python transition (eg 2.6 -> 2.7), then those libraries needs
> to be rebuild AFAIK. However there SONAME is simply:
>
> $ readelf -d /usr/lib/libvtkIOPythonD.so | grep SONAME
>  0x000000000000000e (SONAME)             Library soname:
> [libvtkIOPythonD.so.5.4]

It seems that this would be easy to fix in CMake.  Just include the
python version number in the library name:

libvtkIOPython26D.so.5.4

It's not pretty, but it would work and it would be easy to implement.

> I think most linux distro have a package mecanism which should avoid
> this kind of issue. However I can imagine a user installing python 2.6
> and python2.7 and thus have python symbols resolved from either
> libpython2.6.so or libpython2.7.so ... which IMHO is not a defined
> behavior. Or did someone tool special care to only leave ABI
> compatible python call within those libs (PyFloat_FromDouble,
> Py_BuildValue ...) ? In which case *PythonD are required to never be
> linked explicitely to libpythonZ.Y...

The PythonD libraries are explicitly linked to a particular libpythonZ.Y.
They are only compatible with the version of python they were built
with, and their symbols can only be resolved against that version of
python (even if the symbols did resolve, there would be run-time errors).

 - David

> Anyway I am not asking for a solution, I am simply documenting what I
> did for the VTK package, and the reason why I choose to pick the
> 'shared lib' approach for *PythonD (SOVERSION set to vtk version),
> instead of considering it as a python module.
>
> 2cts
>
> --
> Mathieu