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. 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. :) Anyway, I really wish there were a way to hook into the dynamic link process that didn't require one to manage the entire linkage one's self. The dl.open() function lets you get access to symbols, but that doesn't seem sufficient. :( _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
