On Fri, Apr 04, 2003 at 10:00:16AM -0500, John Ketchum wrote:It turns out that
> Thank you, Jakub. That was indeed the problem. The following command line
> does the trick:
> /usr/bin/gcc -o test test.c -Wl,-dynamic-linker,/lib/ld-linux.so.2,-rpath,/lib
-dynamic-linker,/lib/ld-linux.so.2 is the default, no point of adding it there. /lib is searched by default too. Which means you're trying to run programs with LD_LIBRARY_PATH=/wherever/your/custom/glibc/is/ or have added it to /etc/ld.so.conf and rerun ldconfig. That is the bug, programs against the non-/lib glibc has to be run through its dynamic linker.
Jakub
/usr/bin/gcc -o test test.c -Wl,-rpath,/lib
also works, i.e. it is using the correct loader, but needs to be told to look in /lib to get the correct libraries. Instead it is by default looking in /usr/local/lib for glibc, which has glibc 2.3.1, while using the 2.3.2 loader that is in /lib.
LD_LIBRARY_PATH is not defined,
/usr/local/lib is specified in /etc/ld.so.conf
Is this just a question of search order? Can I just delete all the library files associated with glibc 2.3.1 that are in /usr/local/lib, to force the loader to use the libraries in /lib? (and then re-run ldconfig?)
Or should I just remove /usr/local/lib from /etc//ld.so.conf and rerun ldconfig?-- but then there may be other libraries, not part of glibc-2.3.1, in /usr/local/lib, that would become inaccessible as a result.
The curious thing is that gcc 3.1 appears to be using both the loader and the glibc libraries in /usr/local/lib, and when I try to force it to use those in /lib with the -Wl,-dynamic-linker,/lib/ld-linux.so.2,-rpath,/lib options, I get errors.
Thanks again for your help.
Psyche-list mailing list Psyche-list@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/psyche-list
John Ketchum Qualcomm Inc.
-- Psyche-list mailing list Psyche-list@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/psyche-list
