[Phillip J. Eby wrote]
> ...
> Some variant of the "patch the extensions' runtime path at
> installation/cache extraction time" approach would still be necessary.
Yup, unfortunately.
> 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.
Perhaps 'bin/egg-unzip' or something like that?
> 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.
Yes, that is what I do for ActivePython (and similar for
Active{Tcl|Perl}) for the Unix OSes. Effectively:
configure --prefix=.../some_really_really_long_path
make && make install
> 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
But still "egg-unzip" safe, right? :)
Aside: I've found this page to be quite helpful for cross-platform
shared library handling info:
http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html
Cheers,
Trent
--
Trent Mick
[EMAIL PROTECTED]
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
