Why does ld-linux-x86-64.so.2 link against unexpected location?

I have installed a new glibc in /root/tools/ in debian which already has a pre-installed glibc. For testing the new glibc, I type :

gcc test.c -Wl,-rpath=/root/tools/lib -Wl,--dynamic-linker=/root/tools/lib/ld-linux-x86-64.so.2

produces a.out, then type:

ldd a.out

it shows

linux-vdso.so.1 (0x00007ffd1018c000)
libc.so.6 => /root/tools/lib/libc.so.6 (0x00007fc7f468b000)
/root/tools/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc7f4855000)

But type ls -l /root/tools/lib/ld-linux-x86-64.so.2 , it shows /root/tools/lib/ld-linux-x86-64.so.2 -> ld-2.33.so

Why does ld.so in new glibc link against ld.so in /lib64 ? How to explain this ?

Answer

then type: ldd a.out.

When multiple GLIBC installations are present, you should stop using ldd — it will lie to you.

Instead, do this:

env LD_TRACE_LOADED_OBJECTS=1 ./a.out

That command will tell you what objects are actually loaded.

It looks like your setup is correct and you are simply mislead by ldd.

Update:

Alternatively, using ldd which is in /root/tools/bin/ also displays right result

Yes, but that will display the wrong result for e.g. /bin/date, so that ldd will lie the other way.

If you already know which ldd is the right one to use, you can use it. Just be aware that using the “wrong” ldd will produce confusing output. Something LD_TRACE_LOADED_OBJECTS doesn’t suffer from.