[vtk-developers] Python dll suffix

[Mathieu Malaterre]

On Wed, May 9, 2012 at 8:59 AM, David Gobbi <david.gobbi at gmail.com> wrote:
> 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.

Are you saying this piece of code show go away quick:

$ grep RTLD_GLOBAL -2 Wrapping/Python/vtk/__init__.py.in

if dl and (os.name == 'posix'):
    sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL)

# --------------------------------------


That would be nice. I did not know this issue was finally solved.

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

Make perfect sense.

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

Great. Thanks for the complete clarification.


-- 
Mathieu