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