On 15/09/2011 13.56, [email protected] 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 > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc > _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
