[Python-Dev] next vs darwin

Martin v. Loewis martin@v.loewis.de
01 Feb 2002 00:09:55 +0100


Jack Jansen <Jack.Jansen@oratrix.nl> writes:

> With the define on it loads all extension modules into the application
> namespace. Some people want this (despite the problems sketched above)
> because they have modules that refer to external symbols defined in
> modules that have been loaded earlier (and I assume there's magic that
> ensures their modules are loaded in the right order).

On Unix, this is a runtime option via sys.setdlopenflags (RTLD_GLOBAL
turns on import into application namespace). Do you think you could
emulate this API?

> While I think this is an accident waiting to happen [*] the latter
> behaviour is more-or-less the standard unix behaviour, so it should
> probably be supportable in some way. 

It is not at all standard unix behaviour. Since Python 1.5.2, Python
loads extensions with RTLD_LOCAL on <dlfcn.h> systems, so that each
module has its own namespace. People often requested that this is
changed, but we successfully managed to turn down all these
requests. Eventually, somebody came up with sys.setdlopenflags; this
was good enough for me.

> I prefer the new (OSX 10.1) preferred Apple way of linking plugins
> (which is also the common way to do so on all other non-unix
> platforms) where the plugin has to be linked against the application
> and dynamic libraries it is going to be plugged into, so none of
> this dynamic behaviour goes on.

I'm not sure linking with a libpython.so is desirable, I'm quite fond
of the approach to let the executable export symbols to the
extensions. If that is possible on OS X, I'd encourage you to follow
such a strategy (in unix gcc/ld, this is enabled through
-Wl,--export-dynamic).

> [*] I know of two cases where this already happened: both the curses
> library and the SGI gl library defined a function clear(), so you
> were hosed when you used both in the same Python script.

On Unix, the originally trigger might have been the problem with
initsocket, which was also exported in an Oracle library, thus
breaking Oracle (the Python symbol is now init_socket, but that does
not change the principle).

Regards,
Martin