[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
>
>
