Shared library mysteriously doesn't get linked to application - linux

I have a shared library (libhoard.so) that I'm trying to link with a simple test binary. However, depending on the machine I compile on the shared library doesn't show up in the test binary. I'm not sure what differences exist on the machines and is partly why I'm asking the question. I'm curious what I can do to troubleshoot why the shared library doesn't show up on the test binary on the "broken" machine?
I used this command to compile both binaries (libhoard.so is in the same directory):
$ g++ -L. -lhoard hoard_test.o
Broken machine:
$ ldd a.out
linux-gate.so.1 => (0x00858000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x004dc000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00aaf000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x00675000)
/lib/ld-linux.so.2 (0x00d18000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x0040d000)
Working machine:
$ ldd a.out
linux-gate.so.1 => (0x00110000)
libhoard.so (0x00111000) <----------------- THERE IT IS!
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x03ba8000)
libm.so.6 => /lib/libm.so.6 (0x007a9000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00bf7000)
libc.so.6 => /lib/libc.so.6 (0x0063e000)
libdl.so.2 => /lib/libdl.so.2 (0x007d4000)
libpthread.so.0 => /lib/libpthread.so.0 (0x007db000)
/lib/ld-linux.so.2 (0x0061e000)
Here is some random version information:
Broken machine:
$ uname -srv
Linux 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:18:14 UTC 2011
$ g++ --version
g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Working machine:
$ uname -srv
Linux 2.6.25.3-18.fc9.i686 #1 SMP Tue May 13 05:38:53 EDT 2008
$ g++ --version
g++ (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)

tl;dr version: Add -Wl,--no-as-needed to the link command.
After a series of experimentation and conversations with the OP, I've figured out what's going on.
In the latest version of Ubuntu, ld uses --as-needed by default. What that does is to remove references to libraries that are not explicitly required.
The way Hoard works is as an LD_PRELOAD library. i.e., you are not supposed to need to use functions in libhoard.so directly. Of course, you could link in libhoard directly if you wanted to...unless --as-needed is used, of course.
After discovering this, the solution is simple. Just add -Wl,--no-as-needed to the gcc linking command.

Related

Build gcc from sources - GLIBC

we have old Linux distribution and the vendor doesn't support its updates. We want to build our c++ code with a modern compiler, for that we are building GCC compiler from sources (something very similar to https://github.com/darrenjs/howto/blob/master/build_scripts/build_gcc_10.sh)
Now the problem is that we can not deploy the executables because users' machine do not contain libstdc++.so.6 for this GLIBC. Is there a way to compile GCC and make it based on old local GLIBC that the vendor provides?
[EDIT]: After build my executable of xenenterprise 8.0.0 with GCC 10.1.0 that was built from sources:
[root#xen8 sandbox-gcov]# ldd build/main
linux-vdso.so.1 => (0x00007ffddf9fd000)
libstdc++.so.6 => /var/opt/gcc-10.1.0/lib64/libstdc++.so.6 (0x00007fb82155f000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb82125d000)
libgcc_s.so.1 => /var/opt/gcc-10.1.0/lib64/libgcc_s.so.1 (0x00007fb821045000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb820c77000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb82192c000)
Then got error on another machine with native GCC 4.8.5 20150623 (Red Hat 4.8.5-44):
[root#xen8-1 sandbox-gcov]# ldd build/main
build/main: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by build/main)
build/main: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by build/main)
linux-vdso.so.1 => (0x00007ffeec5fe000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f92099db000)
libm.so.6 => /lib64/libm.so.6 (0x00007f92096d9000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f92094c3000)
libc.so.6 => /lib64/libc.so.6 (0x00007f92090f5000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9209ce3000)

libmodbus.so.5: cannot open shared object file: No such file or directory

Host:Linux BBB-VirtualBox 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Target:Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015 armv7l GNU/Linux
I was compiled libmodbus on host, by running command:
./autogen.sh
./configure --host=arm-linux-gnueabi --prefix=/home/BBB/build
sudo make
sudo make install
and lib and include will be generated in path /home/BBB/build,copied to target system path /usr/local and run sudo ldconfig.
then I build application :
arm-linux-gnueabi-gcc main.c $(pkg-config --libs --cflags ~/BBB/build/lib/pkgconfig/libmodbus.pc)
running on target and it return error:
root#beaglebone:~# ./a.out
./a.out: error while loading shared libraries: libmodbus.so.5: cannot open shared object file: No such file or directory
but I can find libmodbus.so.5 in /usr/local/lib:
root#beaglebone:~# file a.out
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x4bc4bfa11806ebaffdd359ccf3a3144a4fda0a75, not stripped
root#beaglebone:~# find / -name "libmodbus*"
/usr/local/lib/libmodbus.so
/usr/local/lib/pkgconfig/libmodbus.pc
/usr/local/lib/libmodbus.la
/usr/local/lib/libmodbus.so.5.1.0
/usr/local/lib/libmodbus.so.5
/usr/local/include/libmodbus
......
I add the lib path to ld.so.conf and LD_LIBRARY_PATH but still return same error.
root#beaglebone:~# cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
/usr/local/lib
root#beaglebone:~# echo $LD_LIBRARY_PATH
/usr/local/lib:
root#beaglebone:~# ldconfig -p | grep libmodbus
libmodbus.so.5 (libc6) => /usr/local/lib/libmodbus.so.5
libmodbus.so (libc6) => /usr/local/lib/libmodbus.so
I tried add -Wl,-rpath=/usr/local/lib when compiling app,but still return error.
When I config libmodbus and compile app statically,the app running very well.
What should I do?
maybe you can try
ldd a.out
in your terminal and see whether all .so found
I guest there are any .so not found. I have encountered this problem and I solve that by typing ldd some.object in my terminal. And I get something like that
linux-vdso.so.1 => (0x00007ffc32739000)
/usr/local/lib/libusb-driver.so (0x00007fb630a52000)
libmodbus.so.5 => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb630688000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb630484000)
libusb-0.1.so.4 => /lib/x86_64-linux-gnu/libusb-0.1.so.4 (0x00007fb63027b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb63005e000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb630c5a000)
as you can see, the search directory is not necessarily in the directory /usr/local/lib
So I add libmodbus.so.* into /lib/x86_64-linux-gnu/(in my machine, it can be different from yours). I get
linux-vdso.so.1 => (0x00007ffc2e9fe000)
/usr/local/lib/libusb-driver.so (0x00007fa2bbe36000)
libmodbus.so.5 => /lib/x86_64-linux-gnu/libmodbus.so.5 (0x00007fa2bbc2b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa2bb861000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa2bb65d000)
libusb-0.1.so.4 => /lib/x86_64-linux-gnu/libusb-0.1.so.4 (0x00007fa2bb454000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa2bb237000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa2bc03e000)
And I solve this problem.

Build executable on Linux that does not depend on any shared libraries

Environment: Ubuntu 14.04. gcc 4.8.2
I am working on a C++ console application. When I run "ldd" on the executable, I see the following:
linux-vdso.so.1 => (0x00007fffe495e000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9ffa754000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9ffa38e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9ffa087000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9ffaa6e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9ff9e71000
I am wondering if it is possible to define flags on gcc/linker such that the final executable does not depend on any shared libraries.
Simply add -static while linking :-)
Static linking should be avoided not only for security reasons.
BTW: As I know there is no way to create a static lib from a dynamic one. So if you have only the shared lib, you can't link static.

libraries which exist in a binary's elf RUNPATH are not being used?

I have custom built gcc-4.7.2 in my environment. The system gcc is gcc-4.3.4.
I have patched the RUNPATH for all my custom gcc's binaries and shared libraries using patchelf --set-rpath
However, when I run ldd on my 4.7.2 cc1 it picks up the system libstdc++ instead of the one pointed to by the RUNPATH:
$ ldd /sdk/x86_64/2.11.1/gcc-4.7.2/libexec/gcc/x86_64-suse-linux/4.7.2/cc1
libcloog-isl.so.1 => /sdk/x86_64/2.11.1/gcc-4.7.2/lib/libcloog-isl.so.1 (0x00007f072dce8000)
...
libc.so.6 => /lib64/libc.so.6 (0x00007f072bfe0000)
--> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f072bcd5000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f072babe000)
/lib64/ld-linux-x86-64.so.2 (0x00007f072df0d000)
As can be seen the RUNPATH specifies the gcc-4.7.2 library locations:
$ readelf -a /sdk/x86_64/2.11.1/gcc-4.7.2/libexec/gcc/x86_64-suse-linux/4.7.2/cc1 | grep PATH
0x000000000000001d (RUNPATH) Library runpath: \
[/sdk/x86_64/2.11.1/gcc-4.7.2/lib64: \
/sdk/x86_64/2.11.1/gcc-4.7.2/lib: \
/sdk/x86_64/2.11.1/gcc-4.7.2/libexec/gcc/x86_64-suse-linux/lib64: \
/sdk/x86_64/2.11.1/gcc-4.7.2/lib/gcc/x86_64-suse-linux/4.7.2: \
/hostname/sig/lib64: \
/hostname/sig/lib]
I know that libstdc++.so.6 exists in the first entry in the RUNPATH:
$ ls -l /sdk/x86_64/2.11.1/gcc-4.7.2/lib64/libstdc++.so*
lrwxrwxrwx .../sdk/x86_64/2.11.1/gcc-4.7.2/lib64/libstdc++.so -> libstdc++.so.6.0.17
lrwxrwxrwx .../sdk/x86_64/2.11.1/gcc-4.7.2/lib64/libstdc++.so.6 -> libstdc++.so.6.0.17
-rwxr-x--- .../sdk/x86_64/2.11.1/gcc-4.7.2/lib64/libstdc++.so.6.0.17
-rwxr-x--- .../sdk/x86_64/2.11.1/gcc-4.7.2/lib64/libstdc++.so.6.0.17-gdb.py
I don't have an LD_LIBRARY_PATH set in my environment:
$ echo $LD_LIBRARY_PATH
$
How come it doesn't pick up the library found in RUNPATH?
How can I force it to use the gcc-4.7.2 libraries?
The problem is that one of the prerequisites (libppl.so) also imports libstdc++. That prerequisite was built using the system gcc, and therefore finds /usr/lib64/libstdc++.so.6
$ ldd /sdk/x86_64/2.11.1/gcc-4.7.2/lib/libppl.so
linux-vdso.so.1 => (0x00007fffd10db000)
libgmpxx.so.4 => /sdk/x86_64/2.11.1/gcc-4.7.2/lib/libgmpxx.so.4 (0x00007f4716f92000)
libgmp.so.10 => /sdk/x86_64/2.11.1/gcc-4.7.2/lib/libgmp.so.10 (0x00007f4716d26000)
--> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f4716a25000)
libm.so.6 => /lib64/libm.so.6 (0x00007f47167a0000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4716441000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f471622c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f47174b4000)
Once a library has been located by the dynamic linker once, it will no longer be searched for; that location will be used for any subsequent requirements.
I resolved this by rebuilding the prerequisites with the new gcc.
$ ldd /sdk/x86_64/2.11.1/gcc-4.7.2/lib/libppl.so
linux-vdso.so.1 => (0x00007fffd10db000)
libgmpxx.so.4 => /sdk/x86_64/2.11.1/gcc-4.7.2/lib/libgmpxx.so.4 (0x00007f4716f92000)
libgmp.so.10 => /sdk/x86_64/2.11.1/gcc-4.7.2/lib/libgmp.so.10 (0x00007f4716d26000)
--> libstdc++.so.6 => /sdk/x86_64/2.11.1/gcc-4.7.2/lib/../lib64/libstdc++.so.6 (0x00007f4716a25000)
libm.so.6 => /lib64/libm.so.6 (0x00007f47167a0000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4716441000)
libgcc_s.so.1 => /sdk/x86_64/2.11.1/gcc-4.7.2/lib/../lib64/libgcc_s.so.1 (0x00007f471622c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f47174b4000)
I'm thinking the final step is to now rebuild gcc with the newly build prerequisites.
build prerequisites with system gcc
build new gcc
rebuild prerequisites with new gcc
rebuild gcc with rebuilt prerequisites
Whether the final step is necessary I'm not sure.
You need to set the LD_LIBRARY_PATH to point to the desired libstdc++. RUNPATH is evaluated after LD_LIBRARY_PATH.
Quoting from RPATH issue:
The dynamic linker will look for a matching library in the following locations, in this order, which can be changed (see the footnotes below):
1. the DT_RPATH dynamic section attribute of the library causing the lookup
2. the DT_RPATH dynamic section attribute of the executable
3. the LD_LIBRARY_PATH environment variable, unless the executable is setuid/setgid.
4. the DT_RUNPATH dynamic section attribute of the executable
5. /etc/ld.so.cache
6. base library directories (/lib and /usr/lib)

Statically link GMP to an Haskell application using GHC (+ LLVM)

How can I drop dynamic dependency on libgmp and go from this:
linux-vdso.so.1 => (0x00007fffdccb1000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fb01afc1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb01acc7000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb01aabe000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb01a8ba000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb01a69d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb01a2df000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb01b249000)
to this (currently desired):
linux-vdso.so.1 => (0x00007fffdccb1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb01acc7000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb01aabe000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb01a8ba000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb01a69d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb01a2df000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb01b249000)
in a clean and portable way that just works on all GNU/Linux distributions (and not messing up with BSDs (including OS X))?
Do you see any other dependencies that may cause problems in the currently desired list as given above when distributing a single Haskell binary targeting multiple GNU/Linux distributions?
Notes:
my app is GPLv3 so no license violation issues arise regarding GMP
Specifying a path to libgmp.a does not work ( How to selectively link certain system libraries statically into Haskell program binary? ), libgmp is still listed in the ldd output.
If you pass -optl-static -optl-pthread to GHC, it'll statically link all the runtime library dependencies, including GMP. Setting ld-options: -static -pthread in your Cabal file should accomplish the same thing.
That means you'll statically link in glibc too, but that probably won't be a problem, although it might increase binary size quite a bit. Using an alternative libc like musl or uClibc should help counteract that, if it's a problem for you.

Resources