Feature request: Relocatable perl
I don't think it is worth generating a RFE for this, but I'd like to see the ability to relocate or install perl in some place other than the initial install location without everything breaking. This will require cleverness in the manipulation of the search paths for both perl modules and shared objects/DLLs. Alan Burlison
Re: Feature request: Relocatable perl
On Wed, Aug 02, 2000 at 02:58:37PM +0100, Graham Barr wrote: On Wed, Aug 02, 2000 at 02:56:54PM +0100, Alan Burlison wrote: I don't think it is worth generating a RFE for this, but I'd like to see the ability to relocate or install perl in some place other than the initial install location without everything breaking. This will require cleverness in the manipulation of the search paths for both perl modules and shared objects/DLLs. Well I think it is worth an RFC (not that I have time to write one just now) I agree (and likewise). Volunteers? Tim.
Re: Feature request: Relocatable perl
On Wed, 2 Aug 2000, Ken Fox wrote: Tim Bunce wrote: Alan Burlison wrote: the ability to relocate or install perl in some place other than the initial install location without everything breaking. Volunteers? XEmacs does this very well. Can an RFC just say "do what xemacs does" or does it have to be standalone? You've always been able to do this just fine with perl5 too. I've yet to see an example where editing the binaries didn't work. And I'd be very surprised to see anything more portable. After all, if you're using a shared libperl.so (or its perl6 equivalent), the system's loader ld will have encoded the original location of libperl.so somehow into the perl binary and you've got to change it on installation. It's hard for me to see how anything about the perl6 internals could possibly alleviate the need to call ld(1) somewhere in the build process, so I think this matter is off-topic for -internals. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Feature request: Relocatable perl
[EMAIL PROTECTED] wrote:
Graham Barr wrote:
Well I think it is worth an RFC (not that I have time to write one just now)
If only to suggest some sample implementations. Do other languages do it ?
If so how ?
Ok, Ok, I'll do a RFC then... :-)
Actually the only thing affected by LD_LIBRARY_PATH is libperl.so, as
modules are loaded in by dlopen() or equivalent, so the full path in
that case is specified in the call to dlopen().
Solaris 7 onwards has a nice linker feature called $ORIGIN. This allows
the location of run-time linker dependencies to be specified relative to
the location of the executable.
Both Windows and Linux can swing this, too. I believe linux (GNU
Libc, to be precise) uses $ORIGIN in a Solaris-compatible way.
I don't mean to imply, however, the binediting perl has no place.
-John
This is probably best illustrated with
a simple example:
$ pwd
/tmp/app
$ cat bin/main.c
extern void hi();
int main() { hi(); }
$ cat lib/hi.c
#include stdio.h
void hi() { printf("hi!\n"); }
$ cc -G -K pic -o lib/libhi.so lib/hi.c
$ cc -Llib -R '$ORIGIN/../lib' bin/main.c -o bin/main -lhi
$ ldd bin/main
libhi.so = /tmp/app/lib/libhi.so
libc.so.1 = /usr/lib/libc.so.1
libdl.so.1 =/usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
$ bin/main
hi!
$ cd ..
$ mv app somewhere_else
$ ldd somewhere_else/bin/main
libhi.so = /tmp/somewhere_else/lib/libhi.so
libc.so.1 = /usr/lib/libc.so.1
libdl.so.1 =/usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
$ somewhere_else/bin/main
hi!
Another option for ELF based platforms that lack $ORIGIN (i.e.
everything other than Solaris AFAIK) would be to use the (standard?)
libelf library to write a little application that tweaked the RPATH in
the executable appropriately when perl is installed somewhere else other
than the default location. I think this would be far preferable to the
currently used horrible hacks involving either LD_LIBRARY_PATH or
greping and patching the executable.
--
Alan Burlison
Re: Feature request: Relocatable perl
Graham Barr wrote: It is not just libraries, but also the perl @INC that needs to be dynamic Yes, but that seems a bit more tractable - surely we could fiddle with @INC based on the location of the perl interpreter? -- Alan Burlison Solaris Kernel Development, Sun Microsystems
Re: Feature request: Relocatable perl
Insofar as you can pretend to make a good guess at that--perhaps. On Linux: /proc/self/exe What good does that do you? You can't go ../foo with that. It doesn't tell you the real name, just the dev,ino. And it's a nonportable answer that cannot be reproduced everywhere that Perl runs. --tom
