any chance for an explicitely runnable runtime linker?

u-uclibc-y2lt at aetey.se u-uclibc-y2lt at aetey.se
Thu Sep 15 11:56:18 UTC 2011


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



More information about the uClibc mailing list