[Distutils] shared extensions that use other shared extensions

[Michael P. Reilly]

Hi folks,

I ran into a small problem this weekend while working on a potential
redesign of _tkinter.c that I thought I should bring up here.

This is not so much a change to distutils code, or the addition of a
feature.  But it is a big "gotcha" on UNIX, where shared objects could
reside in different directories (as has been discussed here lately).

Just to give a little rundown of the problem.  A few weeks ago, someone
on c.l.py asked if there was a Tcl interpreter extension. Some  people
(including myself) stated that there was one in Tkinter, but couldn't
divorce yourself from Tk.  So I got it in my head to make a Tcl module
then redesign _tkinter.c to use that module instead.

Now the problem:  To be thread safe (especially with Tcl8.0), there is
a global lock object used when entering all the Tcl/Tk code.  This
object should be shared between the two modules (it is using the same
Tcl_Interp object).  Not a problem, right?  In the Python
init_tkinter() function, simply import the Tcl module and get access to
the global data in the shared module.  The import.c code would load the
dynamic modules and handle it.

Not quite.  When the _tkinter.so loads, it attempts to load the Tcl
module shared object as well, not based on sys.path but on
LD_LIBRARY_PATH (or what every was set at link-time).

I got around this by making a PyCObject out of the Tcl lock object in
the module, then accessing that inside init_tkinter(), thereby making
no references to the Tcl module.

Now to my point to all this.  I have two, in fact.

First, when writing modules, try not rely on global data in other
Python modules unless it is thru the Python API.  You might find that
your runtime link-editor can't handle finding the shared library file.

Second, it may not always be enough to place the shared object modules
in site-packages or the like.  I can easily imagine that SWIG might
make references to something inadvertently that is outside the view
that import.c (or the imp module) has of the world.

  -Arcege

-- 
------------------------------------------------------------------------
| Michael P. Reilly, Release Engineer | Email: arcege@shore.net        |
| Salem, Mass. USA  01970             |                                |
------------------------------------------------------------------------