4

I'm trying to run an executable which works fine on my machine on a computer at my university. That computer lacks a compiler, and also libraries that I need, like the boost libs, for instance.

So I've compiled the program on my computer and copied the binary and all the libs I could find using ldd/objdump to the other computer. Unfortunately, when running it I the linker fails to start the program:

LD_LIBRARY_PATH="." ./my_program
./my_program: relocation error: ./libc.so.6: symbol _dl_find_dso_for_object, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

Of course I searched the net: relocation errors seem to occur when a wrong version of some library has been used. However, I can't see how this would be possible when I supply the exact same libraries that are present during compilation.

I read that LD_BIND_NOW can be used to debug dynamic linking; using it, the program segfaults immediately. I compiled a version with -Og -ggdb, executed it at the server and downloaded the resulting core dump to my computer (there is also no gdb on the other computer). Here's the session:

$ gdb ./my_program core
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /my_program...done.

warning: core file may not match specified executable file.
[New LWP 8912]

warning: Can't read pathname for load map: Input/output error.

warning: .dynamic section for "/lib64/ld-linux-x86-64.so.2" is not at the expected address (wrong library or version mismatch?)

warning: Could not load shared library symbols for 14 libraries, e.g. ./libboost_program_options.so.1.54.0.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `./my_program'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000000000056f6 in ?? ()
(gdb) bt
#0  0x00000000000056f6 in ?? ()
#1  0x00007f51ff6fff99 in ?? ()
#2  0x00007ffffb653480 in ?? ()
#3  0x00007f520069bc11 in _dl_relocate_object () from /lib64/ld-linux-x86-64.so.2
#4  0x00007f52006937b1 in dl_main () from /lib64/ld-linux-x86-64.so.2
#5  0x00007f52006a4dde in _dl_load_cache_lookup () from /lib64/ld-linux-x86-64.so.2
#6  0x0000000000000000 in ?? ()
(gdb)

At this point I really don't know how to proceed. I'd welcome any suggestions. Thank you!

PS: Compilation flags look like this (I also tried the flags that I get using -march=native on the target machine):

/usr/bin/c++ \
-Wall -Wextra -Woverloaded-virtual -Wpedantic -std=c++11 -pthread -Og -ggdb \
-Wl,--warn-unresolved-symbols,--warn-once ... -o my_program \
-rdynamic -lboost_program_options -lboost_system -lboost_filesystem -lboost_regex
Community
  • 1
  • 1
Kevin Bader
  • 327
  • 4
  • 11
  • You might have better luck if you avoid copying libraries which are already present on the target machine (especially libc.so.6 and other parts of glibc). Even then, no guarantee -- just another thing to try (some library you've copied might depend on newer glibc, then you're out of luck). – Anton Kovalenko Dec 23 '13 at 21:52
  • 1
    Thanks for the hint. Unfortunately, as soon as I remove libc, I get "/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found". Please correct me if I'm wrong, but don't I always need the same version of libc at compile time and runtime? – Kevin Bader Dec 23 '13 at 23:05
  • You need the same or *newer* version at runtime. That is, always compile for the oldest possible glibc for best portability. (You can use chrooted environment or a virtual machine to choose compilation environment independently on your favorite distribution, OS, version which you prefer as user) – Anton Kovalenko Dec 23 '13 at 23:32
  • 1
    Kevin, did this get resolved? What was the solution? – Component 10 Mar 10 '15 at 11:17
  • No, unfortunately. I ended up having the department install the compiler and libraries on the target machine. If you have the same problem, and manage to find a solution, please post it here -- I'm still curious :) – Kevin Bader Mar 11 '15 at 19:29
  • "`When running it, the linker fails to start the program`" is a very unclear statement in the context of this question. A linker performs only **static** linking. Dynamic linking is performed by the OS to the best of my knowledge. In either case, a linker doesn't "start a program". – barak manos May 15 '15 at 09:45
  • An ldd or an info sharedlibrary on the executable and libraries would help. The most possible culprit though is a lib mismatch/interaction between the libraries you copied over, the libraries in the system (the LD_LIBRARY_PATH variable does not exclude libs under /lib) and the executable. There is also static linking. – Tasos Vogiatzoglou May 15 '15 at 09:52
  • BTW: Is it possible to perform a static link? I know the executable will be real big but it should work. I know that this solves not your basic problem :-) – Klaus May 15 '15 at 10:29
  • perhaps this solution may enlighten: https://stackoverflow.com/a/47115598/2685239 – mariusm May 18 '18 at 09:25

0 Answers0