On 02. 06. 23, 20:09, L A Walsh wrote:

in trying to use a different version of gcc/+libs/+binutils I have run into a problem -- namely that ld seems to use a hard coded path (or two): /home/devel/root/usr/bin> ldd ./ld ./ld: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./ld)  linux-vdso.so.1 (0x00007ffcc6340000)  libbfd-2.40.0.20230412-4.so => not found  libctf.so.0 => not found  libc.so.6 => /lib64/libc.so.6 (0x00007f724619b000)  /lib64/ld-linux-x86-64.so.2 (0x00007f7246c7a000)

The 'ld' prog from binutils ignores LD_LIBRARY_PATH and points to the root to resolve libc,

You did something wrong: /tmp/l> cp /lib64/libc.so.6 . /tmp/l> LD_LIBRARY_PATH=`pwd` ldd /usr/bin/echo linux-vdso.so.1 (0x00007ffea33db000) libc.so.6 => /tmp/l/libc.so.6 (0x00007f69a6417000) /lib64/ld-linux-x86-64.so.2 (0x00007f69a661f000)

a few other libs that are not found and ld-linux-x86-64.so.2 (hard-coded to /lib64 instead of using LD_LIBRARY_PATH

/lib64/ld-linux-x86-64.so.2 is a hardcoded interpreter, so cannot be overriden using LD_LIBRARY_PATH: $ readelf -p .interp /usr/bin/echo String dump of section '.interp': [ 0] /lib64/ld-linux-x86-64.so.2 You can still run the linker manually instead of relying on binaires' .interp: /tmp/l> cp /lib64/ld-linux-x86-64.so.2 . /tmp/l> ./ld-linux-x86-64.so.2 /usr/bin/echo XXX XXX regards, -- js suse labs