This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking


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..?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]