> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Carmelo AMOROSO > Sent: Thursday, September 15, 2011 2:52 PM > To: [email protected] > Subject: Re: any chance for an explicitely runnable runtime linker? > > 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.
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 > > [email protected] > > http://lists.busybox.net/mailman/listinfo/uclibc > > > > _______________________________________________ > uClibc mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc > _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
