This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Question on Glibc add-ons
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Simon <wei dot guo dot simon at gmail dot com>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, libc-help <libc-help at sourceware dot org>
- Date: Tue, 26 Nov 2013 10:07:37 -0800
- Subject: Re: Question on Glibc add-ons
- Authentication-results: sourceware.org; auth=none
- References: <CAB3_kSWP=LLSK+ZvNYdk_Yr0TMk4PQr7Cg0zkW9e68EZu6kLGw at mail dot gmail dot com> <CAAHN_R0nH_S5JdZAN5zzOUbVXaKPqvYmn3Z=Dsq6mWJmJfo9Mg at mail dot gmail dot com> <CAB3_kSWe7RZ8VHGxpnoiaZzHCeUb3QrHYe2NPBmdkWPjvmo1Nw at mail dot gmail dot com>
On Tue, Nov 26, 2013 at 7:18 AM, Simon <wei.guo.simon@gmail.com> wrote:
> I have another question regarding glibc here: In my glibc build
> directory, there is a ld.so as well. It appears to me that the new
> libc.so can only be interpreted by this ld.so. Is it true?
Yes: libc.so.6 and ld.so must match *exactly* (must come from the same
build).
They know about each other's internals, and mix-and-match is not allowed
(doesn't work, as you've discovered).
> 1) I don't understand why since the glibc is the same version 2.5 with
> the old one using by system.
You have different patches. Version 2.5 is meaningless in this context.
> 2) And I am not sure the impact of putting "ld-xx.so" before the
> executable, like " /mnt/simon/usr/lib/ld-2.5.so /mnt/simon/testMtrace
> ". Will there be any potential issues(I noticed some trap utility
> won't work on such process, like gdb)?
The impact is that the executable runs with the loader you gave on command
line, instead of the loader encoded in PT_INTERP segment of the executable.
This does affect external tools, such as GDB.
You *can* run with your new loader without prefixing
every execution: just build your executable with
-Wl,--dynamic-linker=/mnt/simon/usr/lib/ld-2.5.so. This will put
"correct" loader into PT_INTERP (you can verify that with 'readelf -l
/mnt/simon/testMtrace').
>
> 3) Is it a right way to use LD_LIBRARY_PATH environment variable, in
> order to temporarily apply the new glibc to one single
> program(testMtrace)? Is there a better choice?
A better choice is likely to use '-Wl,-rpath=/mnt/simon/usr/lib' when
linking the test program.
HTH,
--
Paul Pluzhnikov