0

I have been getting the error below when compiling and running my application for 64-bit release (release just has optimisation level -O2 on that debug does not).

The 32-bit debug version runs ok. The 64-bit debug version crashes (this is what I am trying to solve), but the 64-bit release version gives me this error. I am guessing that they are related - but not 100% sure about that.

Here is the error:

./tester_x64Linux: relocation error: /home/user/development/lib/libcontroller_library_x64Linux.so.0: symbol nanosleep version GLIBC_2.2.5 not defined in file libpthread.so.0 with link time reference

I am running on ubuntu 18:04 with c++17 standard and I have tested this with gccv7 and gccv8 both with the same results.

Note: that I compile the library with the same make tools (and flags etc) as I do my binary

so /home/user/development/lib/libcontroller_library_x64Linux.so.0 is compiled first and then tester_x64Linux is compiled.

After tsrying to read about what the GLIBC error is trying to tell me, I find I am hitting lots of false positives (in google searches) because there seems to be some oldes issues like GLIBC verno.h file not included in older GBLIC versions (2.0 IIRC). I do have some threads running and I used functions like std::this_thread::sleepfor(...) which I believe use nanosleep under the hood.

So now I am not quite sure how to progress. Usually this would (IMO) imply some library that I have linked needs to be recompiled with newer GLIBC - but in this case its a library that I am compiling and have re-compiled every time I compile my binary (if I do a clean) - so it should be compiled to the same level as my executable.

Maybe my libpthread.so.0 is too old? - but then I would be very confused as I have used this on many other projects (with the same libraries) with no problems (thus far).

update: just tested this against 2 other applications that are built in the exact same way with the same libraries - just different app code, but that have threads - and they are both ok (just confused now).

Any pointers would be appreciated

update 2

My specific flags are (not including warning and include paths - which there are lots)

  • Compiler: -m64 -O2 -g -std=c++17
  • linker: -m64 -O2 -g -rdynamic -lstdc++ -lpthread -lrt -lsystemd -ldl

the main difference with x86 build is that I use flag -m32 instead.

update 3

nm output for nanosleep in libc and libpthread:

[user] ~$ nm -CD --with-symbol-versions /lib/x86_64-linux-gnu/libc.so.6 | grep nanosleep
0000000000130dd0 T __clock_nanosleep@@GLIBC_PRIVATE
0000000000130dd0 W clock_nanosleep@@GLIBC_2.17
00000000000e4760 W nanosleep@@GLIBC_2.2.5
00000000000e4760 T __nanosleep@@GLIBC_2.2.6
[user] ~$ nm -CD --with-symbol-versions /lib/x86_64-linux-gnu/libpthread.so.0 | grep nanosleep
0000000000011d10 W nanosleep@@GLIBC_2.2.5
0000000000011d10 T __nanosleep@@GLIBC_2.2.6

update 4

Precise compiler and linker commands for controller lib:

Note: there are many files, so I will just put in one for as an example - and I will redact some of the include paths to hide project specific details:

Compile

src/bsp_api.cpp
g++ -Wall -Wextra -Wpedantic -Wconversion -Wsign-conversion -Wunreachable-code -Wlogical-op -Wshadow -Wmissing-include-dirs -Wparentheses -Werror -Wno-psabi -Wno-error=deprecated-declarations -Wuseless-cast -Wduplicated-cond -Wnull-dereference -Iinc -Iinc/api -m64 -g -fPIC -std=c++17  -fprofile-arcs -ftest-coverage -DRTI_UNIX -DPLANTUML_DDS_TRACE -DNO_MAIN -c src/bsp_api.cpp -o obj/x64Linux_debug/gcov/src/bsp_api.o

Link

gcc -m64 -g -shared -Wl,-soname,libcontroller_library_x64Linuxd.so.0 -lgcov --coverage -o lib/libcontroller_library_x64Linuxd.so.0.2 OBJS_HERE -lstdc++ -lpthread -lrt -lsystemd

Note: this lib does not have rdynamic - I only use that for executables and not libraries. Note also -lpthread as pointed out, I will start to update this to -pthread at a later time.

LDD

[user] controller_library$ ldd lib/libcontroller_library_x64Linuxd.so.0
        linux-vdso.so.1 (0x00007ffcc7d5a000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa2afe25000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa2afc06000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa2af9ee000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa2af5fd000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa2af25f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa2b0a3a000)

update 5

Searched for all libpthreads on my system. Most of these are cross compiler varients - which are not relevant (and would completely fail at link time due to different arch. The only one I can see that looks "rogue-ish" is ./usr/libx32/libpthread.so - but that is 32bit. There is only 1 64-bit libpthread on my whole system and its the expected one../

[user] /$ find -name "libpthread.so" 2> /dev/null
./usr/lib32/libpthread.so
./usr/lib/x86_64-linux-gnu/libpthread.so
./usr/libx32/libpthread.so
./opt/trl-imx-scs/5.4-zeus/sysroots/aarch64-poky-linux/usr/lib/libpthread.so
./opt/trl-imx-scs/4.14-sumo/sysroots/aarch64-poky-linux/usr/lib/libpthread.so
./opt/trl-imx-6GTcvr/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libpthread.so
./opt/fsl-imx-x11/4.1.15-1.1.1/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libpthread.so
./opt/fsl-imx-x11/4.9.51-mx8-beta/sysroots/aarch64-poky-linux/usr/lib/libpthread.so
./opt/trl-imx-6GTcvr-PECM/5.4-zeus/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi/usr/lib/libpthread.so
./opt/trl-imx-6GTcvr-PECM/4.14-sumo/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/lib/libpthread.so
./opt/trl-ccs-kontron/sdk_v0.1.0/usr/lib/libpthread.so
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
code_fodder
  • 15,263
  • 17
  • 90
  • 167
  • 1
    When faced with an issue like this I usually just start deleting stuff until it goes away, then add things back until it manifests again. With things like `git bisect` you can actually do it more systematically. – tadman Jan 20 '21 at 20:09
  • 2
    From the error message it looks like the version of libpthread.so found by the loader is *not* the one that libcontroller_library_x64Linux.so.0 was originally built against (I think). Hence the symbol version mismatch. – G.M. Jan 20 '21 at 20:26
  • @TedLyngmo my specific flags are (not including warning and include paths - which there are lots) Compiler: `-m64 -O2 -g -std=c++17`, linker: `-m64 -O2 -g -rdynamic -lstdc++ -lpthread -lrt -lsystemd -ldl` - the mainn difference with x86 build is that I use flag `-m32` instead – code_fodder Jan 21 '21 at 07:47
  • @code_fodder Put the line in the question. Don't use `-lpthread` btw. Use [`-pthread`](https://stackoverflow.com/questions/23250863/difference-between-pthread-and-lpthread-while-compiling). – Ted Lyngmo Jan 21 '21 at 07:50
  • A message like "version GLIBC_2.2.5 not defined" means you have a binary built on a different (newer) OS with newer glibc, or with a non-default toolchain. The toolchain is backwards-compatible, but not forwards-compatible. – n. m. could be an AI Jan 21 '21 at 08:21
  • @G.M. thanks for that - but I am not quite sure how that is possible? - the controller library (which is my code) does include other 3rd party libs, but I would have thought if they where incorrect the error would compain about those libs... – code_fodder Jan 21 '21 at 08:23
  • @n.'pronouns'm. This is what I can't understand. I have ubuntu 18:04 64-bit and also multilib (for x86 compiling). The default is gcc7, I have also installed gcc8. I have tried building with gcc7 and gcc8 and both give me the same issue - but there is nothing non-standard on the VM... any thoughts? – code_fodder Jan 21 '21 at 08:25
  • Nitpick: `-rdynamic` is a compiler flag. `-export-dynamic` is the corresponding linker flag. – Ted Lyngmo Jan 21 '21 at 08:33
  • @TedLyngmo - happy with nit-picking :) ... seemed to work though - I guess gcc figured out what I was trying to do, will update. – code_fodder Jan 21 '21 at 08:46
  • :-) `ld: unrecognised option: -rdynamic` is what I get. – Ted Lyngmo Jan 21 '21 at 08:47
  • @TedLyngmo how odd.... I dont get that - maybe I have newer (or older) gcc (tested with both gcc 8.4 and 7.5). But it seems happy with -export-dynamic ... i'll look into that once I get over my current issue! – code_fodder Jan 21 '21 at 08:50
  • do this: `nm -CD --with-symbol-version /lib/x86_64-linux-gnu/libc.so.6 | grep nanosleep` what do you see? Same for `/lib/x86_64-linux-gnu/libpthread.so.0`. – n. m. could be an AI Jan 21 '21 at 09:09
  • @n.'pronouns'm. I have added that to the end of my question - they appear to be the same - is that what you would expect? – code_fodder Jan 21 '21 at 09:43
  • What is the exact command, with every single option, that you are using to build `libcontroller_library_x64Linux.so.0`? What is the output of `ldd libcontroller_library_x64Linux.so.0`? – n. m. could be an AI Jan 21 '21 at 10:36
  • @code_fodder Did you actually type `ld -rdynamic` to see if it accepts that option? – Ted Lyngmo Jan 21 '21 at 11:18
  • @n.'pronouns'm. I have added the compile and link lines (with some sensible omissions like many inc paths, and the list of my objects from the linker). Also the LDD output - nothing special in there. All the extra (third party libs) are included when I do the executable link - there a lots more output from LDD, but if its complaining about controller lib, then I am not sure if that is relevant – code_fodder Jan 21 '21 at 11:40
  • Also I am using gcc to link - so I just read that -rdynamic does : `-rdynamic Pass the flag -export-dynamic to the ELF linker` from: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-rdynamic – code_fodder Jan 21 '21 at 11:46
  • @code_fodder Ok, that's what I was aiming at when I said "_`-rdynamic` is a compiler flag. `-export-dynamic` is the corresponding linker flag_". :-) Ok, that's sorted out then. – Ted Lyngmo Jan 21 '21 at 12:03
  • `-lstdc++` Never do this. Use `g++` as your linker instead. (This may or may not be related to your problem) Also please search for a library named libpthread.so in your entire project, you may have some stray copy. – n. m. could be an AI Jan 21 '21 at 13:18

1 Answers1

0

A guess: you have a bogus libpthread.so.0 somewhere on your system, and that library gets used in preference of the standard /lib/x86_64-linux-gnu/libpthread.so.0.

You did ldd lib/libcontroller_library_x64Linuxd.so.0, but that tells you nothing. You need to do ldd tester_x64Linux instead.

Better sill, do this:

LD_DEBUG=libs,files ./tester_x64Linux

That will tell you which libpthread.so.0 is actually used at runtime.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Ok, thanks for this - I will try this on Monday when I get back in. I did do a search for libpthread - I have the 64 and 32 bit varient, but I did not see much else, I will re-check then. I support I could try a fresh VM and re-test... – code_fodder Jan 23 '21 at 10:13
  • hmm... so its just using the standard one from here: `/lib/x86_64-linux-gnu/libpthread.so.0`. Also I have a lot of other programs that run find with the same setup (different top level app), so I am just surprised it is only this one exe that is complaining – code_fodder Jan 25 '21 at 13:52
  • @code_fodder I have a few other guesses about what may be wrong. Can you show output from `ldd tester_x64Linux`? Does the test `dlopen("libcontroller_library_x64Linuxd.so.0", ...)` or does it link _directly_? Does a trivial `int main() { return 0; }` linked directly against `libcontroller_library_x64Linuxd` with `-Wl,--no-as-needed` flag exhibit the same problem? – Employed Russian Jan 25 '21 at 16:27