I'm currently building a shared object library that use a combination of static and dynamic linking to other libraries. One of the libraries that I want to dynamically link to is librt. However if -lrt is added to the set of arguments passed to libtool, then I don't end up with the necessary reference to library, e.g. output from ldd:
linux-vdso.so.1 => (0x00007fff5273b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5cd720f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5cd6e50000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5cd6c39000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5cd693d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5cd779d000)
However if I hack the generated libtool script and add -lrt to the set of postdeps then I get the appropriate linking:
linux-vdso.so.1 => (0x00007fffb91ff000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1f5ae23000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1f5aa64000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1f5a84d000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1f5a645000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1f5a349000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1f5b3b1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1f5a12b000)
Answer found.
export LIBS=-lrt
Related
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)
I am using using Centos 6.6 and there is a shared library the build generates used by number of executable and any executable using this shared library cannot find it as seen by ldd.
I can locate the library:
$ locate libcs.so.1
/opt/cloudshield/lib/libcs.so.1
ldd shows the following:
$ sudo ldd /opt/cloudshield/lib/libcs.so.1
ldd: warning: you do not have execution permission for `/opt/cloudshield/lib/libcs.so.1'
linux-vdso.so.1 => (0x00007ffff4fff000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7a0fd56000)
/lib64/ld-linux-x86-64.so.2 (0x000000340ba00000)
$ sudo ldconfig -v | grep libcs.so.1
Is it because of the kernel library linux-vdso.so.1?
Executable cannot find the library libcs.so.1:
[fpeter#localhost radius]$ ldd radius
`linux-vdso.so.1 => (0x00007fff634b4000)
libconfd.so => /home/fpeter/trunk/thirdparty/tailf/confd/lib/libconfd.so (0x00007f5db20e6000)
libcs.so.1 => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000340c600000)
libc.so.6 => /lib64/libc.so.6 (0x000000340c200000)
libm.so.6 => /lib64/libm.so.6 (0x000000340ce00000)
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x0000003ba4a00000)
/lib64/ld-linux-x86-64.so.2 (0x000000340ba00000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000340be00000)
libz.so.1 => /lib64/libz.so.1 (0x000000340d600000)
Add /opt/cloudshield/lib/ to your LD_LIBRARY_PATH environment variable, e.g.:
LD_LIBRARY_PATH=/opt/cloudshield/lib
export LD_LIBRARY_PATH
See also How to build library ithoutsudo or
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.
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.
ldd -v appname
linux-gate.so.1 => (0x00949000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00cea000)
libm.so.6 => /lib/libm.so.6 (0x00a83000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00ba1000)
libc.so.6 => /lib/libc.so.6 (0x0015c000)
/lib/ld-linux.so.2 (0x0012f000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00b93000)
Version information:
appname:
libm.so.6 (GLIBC_2.0) => /lib/libm.so.6
libc.so.6 (GLIBC_2.8) => not found
libc.so.6 (GLIBC_2.2) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib/libc.so.6
libc.so.6 (GLIBC_2.7) => not found
libc.so.6 (GLIBC_2.4) => /lib/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.2.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
libstdc++.so.6 (CXXABI_1.3) => /usr/lib/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.5) => /usr/lib/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4) => /usr/lib/libstdc++.so.6
libpthread.so.0 (GLIBC_2.2) => /lib/libpthread.so.0
libpthread.so.0 (GLIBC_2.1) => /lib/libpthread.so.0
libpthread.so.0 (GLIBC_2.0) => /lib/libpthread.so.0
libpthread.so.0 (GLIBC_2.3.2) => /lib/libpthread.so.0
/lib/libpthread.so.0:
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib/libc.so.6
libc.so.6 (GLIBC_2.2) => /lib/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libm.so.6:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/usr/lib/libstdc++.so.6:
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
libgcc_s.so.1 (GCC_4.2.0) => /lib/libgcc_s.so.1
libgcc_s.so.1 (GLIBC_2.0) => /lib/libgcc_s.so.1
libgcc_s.so.1 (GCC_3.3) => /lib/libgcc_s.so.1
libgcc_s.so.1 (GCC_3.0) => /lib/libgcc_s.so.1
libc.so.6 (GLIBC_2.3.2) => /lib/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
libc.so.6 (GLIBC_2.2) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
/lib/libgcc_s.so.1:
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.2.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
appname is compiled on Ubuntu 9.10, trying to run compiled product on Centos 5.
My guess is that Centos5's /lib/libc.so.5 provides up to version GLIBC_2.4, but appname calls for GLIBC_2.8.
But here's the funny thing. This problem didn't happen until I started linking to boost's system library. Before it was just boost's thread library, but now I need both thread and system.
I did compile boost on that Ubuntu system.
I'm now going to try to compile boost on CentOs, and bring over the generated .a files.
I'm linking to the boost .a files btw.
Question, how do I reduce these types of headaches with versioning?
Does any use any tricks like setting up a chroot environment with lower library versions, in which you'd compile a product?
Clearly, compiling on a newer linux distro quickly makes your product incompatible with even the slightest older version of linux.
How do people ship binaries with some decent compatibility?
Yes, I can do static linking, but libc can not be statically linked correct?
Using a chroot environment is one way of doing it, but you don't need all that work. You can set up an older, reference version of your SDK (including libc and others) somewhere, and then force gcc to link against that rather than the libraries and headers in the standard system directories. The GCC options to do so are: -isystem, -isysroot and --sysroot.
As an example, Apple's gcc does that very often, linking to various SDK versions depending which OS version you're targeting.
Actually, I encountering a similiar issue as /usr/lib/libc.so.6: version 'GLIBC_2.33' not found.
This is because a new version of Glibc is available. To fix this, you need to upgrade your Glibc version.
pacman -Sy // update your repo
pacman -S glibc lib32-glibc