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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
