any chance for an explicitely runnable runtime linker?

[Carmelo AMOROSO]

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.

Regards,
Carmelo

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