This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
- From: sgrakkyu at openssl dot it (Oldani Massimiliano)
- To: binutils at sources dot redhat dot com
- Date: Fri, 28 Jan 2005 12:27:23 +0100
- Subject: Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
- References: <20050124222449.GB16078@venus>
On Mon, Jan 24, 2005 at 02:24:49PM -0800, Edward Peschko wrote:
> ....
> What is needed is the ability to reference multiple versions of the
> glibc WITHOUT changing my environment to do so.
>
>
> Ie: If I set up my LD_LIBRARY_PATH to reference:
>
> setenv LD_LIBRARY_PATH /system/path/to/libc:.....
>
>
> then the SuSE executables work fine but my new executables break,
> and if I set up my LD_LIBRARY_PATH to reference:
>
> setenv LD_LIBRARY_PATH /new/path/to/libc:.....
>
> then my new executables work, but my *old* executables break.
>
>
> What I'd like to do is be able to set up my LD_LIBRARY_PATH
> so that I can reference it from the point of view of the
> *executable*:
>
> setenv LD_LIBRARY_PATH "*/../lib:....."
>
>
>
>
> Here, read "* == full path of dirname of executable".
>
> So if gcc was installed in say, "/opt/tools/bin/gcc",
> LD_LIBRARY_PATH would become at runtime "/opt/tools/bin/../lib"
> or "/opt/tools/lib". And hence if I had a libc.so installed
> there, it would pick it up and use it.
>
>
>
> Anyways, I have no idea whether or not this idea is being considered
> or has been considered in the past, but AFAICT it would save me the
> trouble of having hundreds of wrapper scripts. And I would like to
> get an idea of what adding something like this to the gnu toolset would
> require. Discussion is welcome..
>
>
> Ed
>
Using LD_LIBRARY_PATH is not always rialable, it`s not always possible to use it,
for example for SUID/SGID binary and so..?