This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: using different ld-linux.so.2
- From: John Reiser <jreiser at BitWagon dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 13 Mar 2006 10:59:36 -0800
- Subject: 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.)
--