any chance for an explicitely runnable runtime linker?

Filippo ARCIDIACONO filippo.arcidiacono at st.com
Thu Sep 15 13:26:35 UTC 2011


 

> -----Original Message-----
> From: uclibc-bounces at uclibc.org 
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Carmelo AMOROSO
> Sent: Thursday, September 15, 2011 2:52 PM
> To: uclibc at uclibc.org
> Subject: Re: any chance for an explicitely runnable runtime linker?
> 
> On 15/09/2011 13.56, u-uclibc-y2lt at aetey.se wrote:
> > Hello,
> > 
> > We are using, for good reasons, a software setup which would be 
> > extremely complicated to maintain if there were not the 
> possibility to 
> > run the
> > (glibc) runtime linker explicitely (instead of relying on the 
> > compiled-in path to it).
> > 
> > Hence we are bound to glibc for dynamic linking (and to uclibc for 
> > static) because the functionalitites are not available otherwise.
> > 
> > I wonder if it would be hard to implement a corresponding 
> feature for 
> > uClibc's loader. This would not only open for conversion of 
> our setup 
> > to uclibc but certainly would be useful for others too.
> > 
> > I am talking about the following:
> > ----
> > $ /lib/ld-linux.so.2
> > Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You 
> > have invoked `ld.so', the helper program for shared library 
> executables.
> > This program usually lives in the file `/lib/ld.so', and special 
> > directives in executable files using ELF shared libraries tell the 
> > system's program loader to load the helper program from this file.  
> > This helper program loads the shared libraries needed by 
> the program 
> > executable, prepares the program to run, and runs it.  You 
> may invoke 
> > this helper program directly from the command line to load 
> and run an 
> > ELF executable file; this is like executing that file itself, but 
> > always uses this helper program from the file you 
> specified, instead 
> > of the helper program file specified in the executable file 
> you run.  
> > This is mostly of use for maintainers to test new versions 
> of this helper program; chances are you did not intend to run 
> this program.
> > 
> >   --list                list all dependencies and how they 
> are resolved
> >   --verify              verify that given object really is 
> a dynamically linked
> >                         object we can handle
> >   --library-path PATH   use given PATH instead of content 
> of the environment
> >                         variable LD_LIBRARY_PATH
> >   --inhibit-rpath LIST  ignore RUNPATH and RPATH 
> information in object names
> >                         in LIST
> >   --audit LIST          use objects named in LIST as auditors
> > ----
> > 
> > One of the crucial things is "--library-path" - which is 
> not inherited 
> > by child processes, in contrast to LD_LIBRARY_PATH. This gives a 
> > possibility to safely specify the actual (loader and/or) 
> library instance per process.
> > 
> > (--inhibit-rpath option is a very useful one too, but I would also 
> > happily live with it being the default, say by loader compile-time 
> > option)
> > 
> > Regards,
> > Rune
> > 
> 
> You are referring to stand-alone execution mode.
> It is support in master now. You need to configure uClibc to 
> enebale it.

Must be enable LDSO_STANDALONE_SUPPORT.
To note, the ldso stand-alone execution supports only "--library-path PATH"
Option, this is the minimal support to get the prelink working.

> 
> Regards,
> Carmelo

Filippo.
> 
> > _______________________________________________
> > uClibc mailing list
> > uClibc at uclibc.org
> > http://lists.busybox.net/mailman/listinfo/uclibc
> > 
> 
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
> 



More information about the uClibc mailing list