[Python-Dev] next vs darwin

[Jack Jansen]

On Wednesday, January 30, 2002, at 09:42  PM, Steven Majewski wrote:
> dlcompat libs are used by Apple to build Apache and some other 
> programs.
> The libs are not included in Mac OSX, although the sources are 
> available
> in the Darwin CVS, and an improved version is distributed on Fink and
> maybe other places. Since additional libs are required, I would not
> make that the default. ( unless, since there's already a check for
> libdl in config, we make it dependent on that. )
>
> The problem is that  the current dynload_next is broken, and we've
> had some problems replicating tests and solutions because, among other
> problems, of the very poor error reporting in dynload_next, everyone
> is starting from a differently hacked version of the 2.2 distribution.
> (The other variable is which modules and packages people are loading.)
>
> Reportedly, using the dlcompat libs fixes some problems for 
> some people.

I'm not too thrilled with dlcompat. First and foremost, it fixes 
some problems for some people but may introduce problems for 
others (if I understand correctly). And then there's the issue 
of it not being part of the base MacOSX distribution.

I now have a dynload_next.c (that I'll check in tomorrow) that 
can behave in two ways based on a #define.

With the define off it loads every extension module in a 
separate namespace, i.e. two independent modules can never break 
each other by supplying external symbols the other module 
expected to load from a completely different place.

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

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. 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 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. And the SGI compression library contains a private 
version of libjpeg with no symbol renaming, so if you used the 
cl module and a module which linked against the normal libjpeg 
you were also hosed.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -