[Distutils] Dynamic linking on Linux, Mac OS, et al

[Bob Ippolito]

On Jan 6, 2006, at 9:55 PM, Phillip J. Eby wrote:

> At 12:59 PM 1/7/2006 +0800, Jeff Pitman wrote:
>>  If you need .so that's built and exported by the same packaged  
>> egg, you
>> may just consider installing it in a more benign area such as /usr/ 
>> local/lib.
>
> As I mentioned before, this breaks multi-version support, although I
> suppose one could perhaps force the egg version to always be  
> included in
> the filename...  that would lead to some interesting problems as  
> far as
> keeping the build area clean, though!  You'd have to run a "clean -- 
> all"
> whenever the version number changed, and the extensions using the  
> library
> would have to refer to the exact version.
>
> Unfortunately, this would *still* require users to mess with
> LD_LIBRARY_PATH in order to use private library versions, and so isn't
> particularly useful.  Some variant of the "patch the extensions'  
> runtime
> path at installation/cache extraction time" approach would still be  
> necessary.
>
> There is actually a hook in pkg_resources whose purpose was to support
> doing this kind of thing with any code resources extracted to the egg
> cache, so it's probably doable, and I could probably also make the  
> code
> usable by easy_install during egg unpacking.  It pretty much means the
> "unzip the egg manually" concept is a dead duck when libraries are
> involved, though.  You could only safely unpack an egg using a
> manually-created ResourceManager with an appropriate extraction  
> path base.
>
> On Mac OS there's an option to automatically pad the rpath area,  
> but on
> other OSes I'd need to do the padding myself by supplying an extra- 
> long
> rpath entry that could then be overwritten during the extraction  
> process.

IIRC, you can't set that any DYLD environment variables after the  
process has started... has to happen before main() is even called.

> What bothers me about all of this is that moving an installed egg then
> *breaks* it, because the rpath is now hard-wired.  Sigh.  Ironically
> enough, an egg containing a shared library would then need to be  
> labeled as
> "not unzip safe", i.e., it's really only safe to use if it remains
> zipped.  A new category of egg, to be sure.  :)
>
> Interestingly, this is one of the few times where I have to say that
> Windows is actually better-designed than Unix.  Sure, the same design
> choice enables all other sorts of DLL hell, but on this very narrow
> specific issue Windows kicks ass.  :)

Well, it's not really the design that's better, just the defaults...  
for a questionable definition of better :)

-bob