[vtk-developers] Python dll suffix

Mathieu Malaterre mathieu.malaterre at gmail.com
Tue May 8 06:46:40 EDT 2012


Hi David,

On Wed, May 2, 2012 at 7:19 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> The "D" stands for .dylib, which is the shared library suffix on OS X.
>
> Originally, the python modules had a ".dll" suffix on Windows and
> a ".so" suffix on Linux.  This meant that python modules were really
> just shared libraries with a special python "init" function.  As far as
> the linker was concerned, there was no difference between a python
> module and a shared library.
>
> With OS X, shared libraries end in ".dylib" and python modules end
> in ".so", so it was no longer possible to have the python modules
> act as both modules, and as link libraries.  This distinction was also
> recognized by cmake (though I forget in what version).  Also, on
> Windows, python started to require that python modules end in ".pyd"
> as of python 2.5.
>
> To support OS X (and later Windows), it was necessary to break the
> python wrappers into two parts: one part that is a shared library (the
> "D" part, which is a .dylib on OS X, hence the "D"), and another part
> that is a python module.

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) ?

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]

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

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



More information about the vtk-developers mailing list