This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: using different ld-linux.so.2


Guillaume Duranceau <guillaume.duranceau@bull.net>:
> There's no way to use a second glibc being simple user on the system, without
> relinking programs and having child processes using the same glibc as their
> father (if there is one actually, please, let me know...). I wonder what
> solution glibc hackers use to perform tests on their systems.

The glibc internal tests are run by invoking the new ld.so explicitly
and using --library-path, such as:
   build-i686-linuxnptl/elf/ld-linux.so.2 --library-path \
      build-i686-linuxnptl:build-i686-linuxnptl/math:...  test-program arg1...

I have a web page and code for using an indirect runtime loader,
which on x86 semi-automates much of the mechanics of choosing glibc:
http://BitWagon.com/rtldi/rtldi.html

If the application programs always use a shared library [such as libc.so]
to perform the system call execve(), then it is conceivable to meet the
goal of "a child process uses the same glibc as its parent" by using
LD_PRELOAD of a library that intercepts execve() and invokes the new process
using ld.so and --library-path.  By combining this with rtldi, it seems
possible also to keep the original "process name" (instead of all processes
appearing as "ld-linux" in the output from /bin/ps.)

-- 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]