2

I am getting the wrong .so at runtime even though I specified the right one at compile time:

samiam@samiam-linux-pc:~/projects/petit_ami$ make event
gcc -g3 -o event xterm.c event.c libc.so -lm 
samiam@samiam-linux-pc:~/projects/petit_ami$ ./event
./event: relocation error: ./event: symbol ovr_write version 
GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
samiam@samiam-linux-pc:~/projects/petit_ami$ ldd event
    linux-vdso.so.1 (0x00007ffda5ffa000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe641048000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe641642000)
samiam@samiam-linux-pc:~/projects/petit_ami$

I am using an alternative glibc .so, located in the current directory. I was able to prove that gcc is linking to the correct library, because if I remove the libc.so file, it complains about missing files. Also, if I remove the libc.so file from the gcc command line, I get the missing reference at runtime.

So the gcc works against my libc.so at compile time, but at runtime it goes to the standard location for libc.so instead of the local file. LD_DEBUG also shows this behavior. I also tried putting "." on the LIBRARY_PATH at first position, it had no effect.

The ideal answer would be to place a directory in the search order ahead of the others (as I tried to do with LIBRARY_PATH), since I define several local libs, not all with the same name.

Scott Franco
  • 481
  • 2
  • 15
  • 1
    What's the output of `readelf -d event | grep NEEDED`? Also run that commend against your custom `.so` files to see if they explicitly link to something in `/usr/lib`. – Nikos C. May 30 '19 at 16:03
  • Also, try `LD_LIBRARY_PATH` instead of `LIBRARY_PATH`. – Nikos C. May 30 '19 at 16:06
  • samiam@samiam-linux-pc:~/projects/petit_ami$ readelf -d event | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] – Scott Franco May 30 '19 at 16:06
  • Of interest: the command: samiam@samiam-linux-pc:~/projects/petit_ami$ gcc -g3 -o event xterm.c event.c -L. -lm /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In function `_start': (.text+0x12): undefined reference to `__libc_csu_fini' (.text+0x19): undefined reference to `__libc_csu_init' collect2: error: ld returned 1 exit status - If I eliminate the local libc.so this error goes away, so this SEEMS to force it to use the local file, which appears to be missing something. The glibc was compiled from the current tip with modifications. – Scott Franco May 30 '19 at 16:08
  • In that case it seems the other libraries your executable uses need the system glibc. This can happen indirectly too. For example one of your custom libs needs a system lib which needs the system glibc. – Nikos C. May 30 '19 at 16:11
  • Sure, that is the idea, actually. I just needed to add an extra call to glibc. So apparently there is a mismatch between what they expect and what is in the glibc tip. – Scott Franco May 30 '19 at 16:12
  • None of this occurs with .a (abosolute) linking by the way. the issue occurs because I want to use GTK, and GTK does not tolerate static linking. – Scott Franco May 30 '19 at 16:14
  • Add something like `-L/usr/local/lib -Wl,-R,/usr/local/lib -Wl,--enable-new-dtags` to you compile/link command. `--enable-new-dtags` uses `RUNPATH` (as opposed to `RPATH`), and allows `LD_LIBRARY_PATH` overrides. – jww May 30 '19 at 16:23
  • *"... but at runtime it goes to the standard location for libc.so instead of the local one..."* - Yeah, a bunch of idiots thought it was a good idea to compile and link against one version of a library, and then runtime link against the wrong version of the library. They should get a [Darwin award](https://darwinawards.com/darwin/) for the decisions. By the way, Linux is the only major OS to suffer the problems out of the box. AIX, BSDs, OS X, Solaris and even Windows managed to solve it... – jww May 30 '19 at 16:26
  • So IMHO, I really don't like .sos, static linking allows me to form a complete binary at runtime, and avoid all of the problems. I got dragged into this one by GTK not being able to link statically. Uggh. – Scott Franco May 30 '19 at 16:51
  • I think I probably suceeded, or at least forced gcc to REALLY link to my .so, and so I've moved on to the next circle of hell: https://stackoverflow.com/questions/6656317/linking-a-c-program-directly-with-ld-fails-with-undefined-reference-to-libc-c – Scott Franco May 30 '19 at 16:56

0 Answers0