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/%7Ejack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -