This is the mail archive of the
mailing list for the glibc project.
Re: using different ld-linux.so.2
- From: Guillaume Duranceau <guillaume dot duranceau at bull dot net>
- To: libc-alpha at sourceware dot org
- Cc: Mike Frysinger <vapier at gentoo dot org>
- Date: Tue, 11 Apr 2006 16:07:59 +0200
- Subject: Re: using different ld-linux.so.2
- References: <email@example.com> <firstname.lastname@example.org>
Linking programs against a new glibc seems to be done like this:
> ... just link your programs with:
> -Wl,-dynamic-linker,/newglibc/lib/ld-linux.so.2 -Wl,-rpath,/newglibc/lib
I tried this with several glibc 2.3.x on systems running glibc 2.3.y without
any problems. But with glibc 2.4 on a system running glibc 2.3.5, I obtain
the following linker error:
/lib/libc.so.6: undefined reference to '_dl_out_of_memory@GLIBC_PRIVATE'
Using the --verbose option of ld, we can see:
ld-linux.so.2 needed by /lib/libc.so.6
found ld-linux.so.2 at /newglibc/lib/ld-linux.so.2
The original libc.so.6 tries to use the new ld-linux.so.2, resulting in an
error. If I temporarily "remove" the new ld-linux.so.2 during the
compilation, the problem disappears (the original ld-linux.so.2 is found).
Actually, ld-linux.so.2 seems to be firstly searched in directories listed in
rpath. But rpath should not be used by the linker to search anything (it's
just the RUNTIME library search path of the created executable).
Am I missing something? Is this ld behaviour "correct"? Should I ask on the
binutils mailing list?