1

I compiled a simple C(only contained an empty main function) file into a.out, and run it in different loaction:

user@host:~$ md5sum /home/work/a.out /tmp/a.out
dcbdb836569b99a7dc83366ba9bb3588  /home/work/a.out
dcbdb836569b99a7dc83366ba9bb3588  /tmp/a.out
user@host:~$
user@host:~$
user@host:~$ ldd /home/work/a.out
    linux-vdso.so.1 (0x00007fffe11fa000)
    libc.so.6 => /opt/compiler/gcc-4.8.2/lib/libc.so.6 (0x00007f42b8bca000)    <--
    /opt/compiler/gcc-4.8.2/lib64/ld-linux-x86-64.so.2 (0x00007f42b8f77000)
user@host:~$
user@host:~$ ldd /tmp/a.out
    linux-vdso.so.1 (0x00007fff6ba41000)
    libc.so.6 => /tmp/../lib64/tls/libc.so.6 (0x0000003f0b000000)    <--
    /opt/compiler/gcc-4.8.2/lib64/ld-linux-x86-64.so.2 (0x00007f12f537a000)

Why it loaded different libc.so?


Here are more information, thanks for @qubert

$ readelf -a ./a.out | fgrep ORIGIN
0x000000000000000f (RPATH)              Library rpath: [$ORIGIN:$ORIGIN/lib:$ORIGIN/lib64:$ORIGIN/../lib:$ORIGIN/../lib64:/opt/compiler/gcc-4.8.2/lib:/opt/compiler/gcc-4.8.2/lib64]

$ gcc -v -g 1.c 2>&1 | fgrep collect
/home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../libexec/gcc/x86_64-xxx-linux-gnu/4.8.2/collect2 -rpath $ORIGIN:$ORIGIN/lib:$ORIGIN/lib64:$ORIGIN/../lib:$ORIGIN/../lib64:/opt/compiler/gcc-4.8.2/lib:/opt/compiler/gcc-4.8.2/lib64 --sysroot=/home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../x86_64-xxx-linux-gnu/sys-root --eh-frame-hdr -m elf_x86_64 -dynamic-linker /opt/compiler/gcc-4.8.2/lib64/ld-linux-x86-64.so.2 /home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../lib/gcc/x86_64-xxx-linux-gnu/4.8.2/../../../../lib64/crt1.o /home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../lib/gcc/x86_64-xxx-linux-gnu/4.8.2/../../../../lib64/crti.o /home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../lib/gcc/x86_64-xxx-linux-gnu/4.8.2/crtbegin.o -L/home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../lib/gcc/x86_64-xxx-linux-gnu/4.8.2 -L/home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../lib/gcc -L/home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../lib/gcc/x86_64-xxx-linux-gnu/4.8.2/../../../../lib64 -L/home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../x86_64-xxx-linux-gnu/sys-root/lib/../lib64 -L/home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../x86_64-xxx-linux-gnu/sys-root/usr/lib/../lib64 -L/home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../lib/gcc/x86_64-xxx-linux-gnu/4.8.2/../../../../x86_64-xxx-linux-gnu/lib -L/home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../lib/gcc/x86_64-xxx-linux-gnu/4.8.2/../../.. -L/home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../x86_64-xxx-linux-gnu/sys-root/lib -L/home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../x86_64-xxx-linux-gnu/sys-root/usr/lib /tmp/ccbKeW7k.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../lib/gcc/x86_64-xxx-linux-gnu/4.8.2/crtend.o /home/opt/gcc-4.8.2.xxx-r4/gcc-4.8.2.xxx-r4/sbin/../lib/gcc/x86_64-xxx-linux-gnu/4.8.2/../../../../lib64/crtn.o
  • 1
    Guess: you have LD_LIBRARY_PATH set to something weird. – muru Oct 17 '18 at 10:32
  • @Guess, nope my LD_LIBRARY_PATH = /usr/local/lib:. Additionally, $ LD_LIBRARY_PATH=/opt/compiler/gcc-4.8.2/lib64/libc.so.6 /tmp/a.out does not work, but $ LD_PRELOAD=/opt/compiler/gcc-4.8.2/lib64/libc.so.6 /tmp/a.out is OK! – da_miao_zi Oct 18 '18 at 3:24
  • It looks like the binary is using $ORIGIN in its DT_RPATH or DT_RUNPATH; please append the output of readelf /tmp/a.out | grep ORIGIN and the output of gcc -v <your_file.c> 2>&1 | grep collect to your question. – qubert Oct 20 '18 at 16:28
1

Your compiler was configured to set DT_RPATH with $ORIGIN by default using its built-in specs.

The purpose of $ORIGIN is to create executables that could be moved elsewhere together with the shared libraries they depend on: if a binary is moved to /alt/opt/bin and has $ORIGIN/../lib in its runpath, the dynamic linker will first look for its libraries in /alt/opt/lib. More details in the ld.so(8) manpage.

The problem with your compiler is that it's using the deprecated DT_RPATH (instead of DT_RUNPATH), which is always searched first and cannot be overridden via LD_LIBRARY_PATH. To avoid that, try using -Wl,--enable-new-dtags to gcc:

gcc -Wl,--enable-new-dtags file.c

That will direct the linker to use DT_RUNPATH instead of DT_RPATH for the -rpath option, whether set on the command line or via specs. This is supposed to not be supported on older systems, but as far as I remember, that was quite a while ago.

  • Thank you for the detailed and informative response! – da_miao_zi Oct 23 '18 at 3:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.