I use the jsoncpp lib in my linux cli tool.
The CMakeLists.txt contains
find_library(LIB_JSON jsoncpp)
target_link_libraries(${PROJECT_NAME} ${LIB_JSON})
The result is
/usr/bin/c++ -rdynamic CMakeFiles/cktwagent.dir/agent_main.cpp.o -o cktwagent -ljsoncpp
When i check the binary I found:
$> ldd cktwagent
linux-vdso.so.1 (0x00007ffe4cfd1000)
libjsoncpp.so.24 => /usr/lib/libjsoncpp.so.24 (0x00007f87505bd000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f87503e0000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f875029a000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f8750280000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f87500b7000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f87506ce000)
Why ld use /usr/lib/libjsoncpp.so.24 and not the symbolic link /usr/lib/libjsoncpp.so?
Why the ld sometime resolv the linbrary link to the real library file?
$> ls -l /usr/lib/libjsoncpp.so
lrwxrwxrwx 1 root root 16 26. Sep 17:02 /usr/lib/libjsoncpp.so -> libjsoncpp.so.24
In case of /usr/lib/libstdc++.so.6 the ld use the symbolic link. When i check the path from ldd output, libstdc++.so.6 point to a symbolic link.
$> ls -l /usr/lib/libstdc++.so.6
lrwxrwxrwx 1 root root 19 9. Nov 12:43 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.28
I like to understand this behavior. Because when i copy the binary to a different system, the link to libjsoncpp.so available. But it points to some different version.
Many thanks
Thomas
That's a version compatibility feature. By convention, API compatibility is determined by the major version number. So 6.0.28 would be is compatible with 6.1.1, but not with 5.0.1 or 7.0.1.
To allow for compatible upgrades, libstdc++.so.6.0.28 is symlinked as libstdc++.so.6. Then it can be binary-upgraded to e.g. libstdc++.so.6.0.29 without touching applications that rely on API version 6 of libstdc++.
In addition, it allows libraries with different major version numbers to coexist on the same system. Installing libstdc++.so.7.0.0 will not break apps that link against libstdc++.so.6.
Why ld use /usr/lib/libjsoncpp.so.24 and not the symbolic link /usr/lib/libjsoncpp.so?
That's because libjsoncpp has a soname of libjsoncpp.so.24. Apparently it is following the same convention of having the major version number determine compatibility.
You can achieve the same behavior with your shared lib libfoo if you link it like this:
gcc -shared -Wl,-soname,libfoo.so.<major> -o libfoo.so.<major>.<minor>
For more details refer to GCC Howto - Version numbering, sonames and symlinks.
Related
I have an application configured using CMake and build with GCC. I'm building on one Linux system and try to run it on another. Unfortunately both systems supply different versions of the same lib. For example GLEW, so whenever I try to run executable on the second system I'm getting this:
./app
./app: error while loading shared libraries: libGLEW.so.2.0: cannot open shared object file: No such file or directory
Here are relevant outputs of app reference and what I have in my system.
ldd ./app | awk '{print $1}' | grep GLEW
libGLEW.so.2.0
ldconfig -p | grep GLEW
libGLEW.so.2.2 (libc6,x86-64) => /usr/lib/libGLEW.so.2.2
libGLEW.so.2.2 (ELF) => /usr/lib32/libGLEW.so.2.2
libGLEW.so.2.1 (libc6,x86-64) => /usr/lib/libGLEW.so.2.1
libGLEW.so (libc6,x86-64) => /usr/lib/libGLEW.so
libGLEW.so (ELF) => /usr/lib32/libGLEW.so
I actually would like to configure CMake or whatever to reference the "least common denominator" filename, so instead of libGLEW.so.2.0 it should ref to libGLEW.so
[EDIT]
Some additional outputs from the builder OS:
cat CMakeCache.txt | grep GLEW
...
GLEW_LIBRARIES:FILEPATH=/usr/lib/x86_64-linux-gnu/libGLEW.so
...
ls -al /usr/lib/x86_64-linux-gnu/libGLEW.so
lrwxrwxrwx 1 root root 16 Jan 12 2019 /usr/lib/x86_64-linux-gnu/libGLEW.so -> libGLEW.so.2.1.0
So basically CMake gets it right, but then the GCC linker follows the link and actually places a version specific filename as a reference.
In this case I would instruct cmake to link against the shared library generic name, which should be libGLEW.so or similar and be a symbolic link to a specific version of the library. Check in /usr/lib. If it does not exist on the build machine or the execution machine, you may need to create it. However, note that there may not be binary compatibility between two versions of libGLEW, as #AlanBirtles pointed out.
As of cmake 3.15 there is now a cmake module to find glew and handle this better.
Here is a link to the module:
https://cmake.org/cmake/help/latest/module/FindGLEW.html?highlight=glew
You should be able to figure it out from there.
For now I have converged on using patchelf. The solution is based on How can I change the filename of a shared library after building a program that depends on it?
Install patchelf on your linux build host. In my case it's ubuntu,
so apt-get install -y patchelf
Check the app dependencies: patchelf --print-needed ./app, which in my case yields:
libSDL2-2.0.so.0
libpthread.so.0
libGL.so.1
libGLU.so.1
libGLEW.so.2.1
libfontconfig.so.1
libfreetype.so.6
libXcursor.so.1
libX11.so.6
libdl.so.2
libIL.so.1
libminizip.so.1
libz.so.1
libunwind.so.8
libvorbisfile.so.3
libopenal.so.1
libcurl.so.4
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
Next replace the links to all missing libraries. In my case it was only libGLEW.so.2.1, so patchelf --replace-needed libGLEW.so.2.1 libGLEW.so ./app
Now re-verify of the list of linked libs: patchelf --print-needed ./app
libSDL2-2.0.so.0
libpthread.so.0
libGL.so.1
libGLU.so.1
libGLEW.so
libfontconfig.so.1
libfreetype.so.6
libXcursor.so.1
libX11.so.6
libdl.so.2
libIL.so.1
libminizip.so.1
libz.so.1
libunwind.so.8
libvorbisfile.so.3
libopenal.so.1
libcurl.so.4
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
Note libGLEW.so.2.1 got changed into libGLEW.so
P.S. I don't consider this a proper solution, so any suggestions how to handle linking properly in the first place are more than welcome.
I've built a debug version of a shared library (OpenSSL) so I can step through a certain function with a debugger to better understand what's going on.
However, I'm having a difficult time actually linking with the debug version I've built. For some reason, no matter what I do, the linker always ends up linking with the pre-installed system version, even though both versions are in the usr/lib directory, the soft-links are setup correctly (AFAIK), and I explicitly specify the debug lib on the command line when compiling.
So the original (system-installed) version of the shared library is:
>ls /usr/lib/x86_64-linux-gnu/ -lh | grep libssl
lrwxrwxrwx 1 root root 15 Sep 23 2016 libssl.so -> libssl.so.1.0.0
-rw-r--r-- 1 root root 386K Sep 23 2016 libssl.so.1.0.0
And the debug version, which I compiled from source and configured as a shared library (using the fPIC flag for all object files), is:
>ls /usr/lib/ -lh | grep libssl
lrwxrwxrwx 1 root root 29 Oct 19 11:31 libssldebug.so -> /usr/lib/libssldebug.so.1.0.2
-rwxr-xr-x 1 root root 2.3M Oct 19 00:53 libssldebug.so.1.0.2
And it's the same with the other OpenSSL shared library, libcrypto. I have a libcryptodebug.so.1.0.2 and a corresponding soft link in /usr/lib.
So, I try to build an executable and link against the debug shared lib like this:
>g++ test.cpp -o test -std=c++14 -lssldebug -lcryptodebug -I openssl-1.0.2p/include/
And it compiles and links with no errors.
And YET... when I examine the executable with ldd, I see:
>ldd test
linux-vdso.so.1 (0x00007ffcaa39b000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007ff717d37000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007ff71793b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff717630000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff71732f000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff717119000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff716d6e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff716b6a000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff717f98000)
So even though I explicitly linked with -lssldebug, and it compiled and linked with no errors, ldd still shows that the linker for some reason is linking with the non-debug version (/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0). I also tried running ldconfig and then recompiling/linking, but it still links with the old (non-debug) version.
So what is going on here? What am I doing incorrectly that causes it to silently ignore the command line linker arguments and somehow just default to using the non-debug version (which has a completely different shared lib name!) somehow?
So even though I explicitly linked with -lssldebug, and it compiled and linked with no errors, ldd still shows that the linker for some reason is linking with the non-debug version (/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
You are mixing up static linking, and runtime loading (sometimes also called dynamic linking).
When you link with g++ test.cpp ... -lssldebug ..., you are linking with libssldebug.so, but (as ldd output tells you) that library is not used during runtime loading.
That is happening because libssldebug.so has a special dynamic tag DT_SONAME, which contains "libssl.so.1.0.0", and the static linker records that name as the library to be loaded at runtime.
You can confirm this with:
readelf -d libssldebug.so | grep SONAME
You can examine the libraries that runtime loader will try to locate for a given executable with:
readelf -d ./test | grep NEEDED
Now that you understand the problem, how do you fix it?
One of two ways:
You could change the SONAME encoded in libssldebug.so, by relinking it with -Wl,--soname=libssldebug.so.1.0.2, and then relinking your test program. Use above readelf commands to verify that SONAME and NEEDED now contain "libssldebug.so.1.0.2", and then ldd to verify that libssldebug.so.1.0.2 is what the runtime loader will use.
Alternatively, it may be simpler to install libssldebug.so into a different directory (say /tmp/libssldebug), create a symlink libssl.so.1.0.0 -> lissldebug.so in that directory, and then ask the runtime loader to search this directory first with g++ test.cpp ... -Wl,--rpath=/tmp/libssldebug. With this solution, the executable will still search for libssl.so.1.0.0, but it will search for it in the /tmp/libssldebug directory first, and will find your copy.
I have some code using the SystemC library which compiles fine when I'm physically at the machine, but throws undefined references when I'm ssh'ing in.
g++ -Wno-deprecated -O0 -g3 -I/path/to/include socex2.cpp -L/path/to/lib -lsystemc
/tmp/ccCNdiMA.o: In function `sc_dt::sc_uint_base::print(std::ostream&) const':
/path/to/include/sysc/datatypes/int/sc_uint_base.h:844: undefined reference to `sc_dt::sc_uint_base::to_string[abi:cxx11](sc_dt::sc_numrep, bool) const'
collect2: error: ld returned 1 exit status
At first I thought it was a problem with LD_LIBRARY_PATH, set in ~/.bashrc to /path/to/lib. I source ~/.bashrc in ~/.bash_profile for non-interactive sessions such as ssh.
To verify, here's the relevant bits of /usr/bin/env:
TERM=xterm
SHELL=/bin/bash
SSH_CLIENT=xx.xx.xx.xx 56176 22
LD_LIBRARY_PATH=/path/to/lib
SSH_CONNECTION=xx.xx.xx.xx 56176 yy.yy.yy.yy 22
_=/usr/bin/env
Why won't my program link? The headers and libraries I'm using are exactly the same and in the exact same places.
P.S.
I don't have admin access on these machines
gcc is 5.4.0
OS is Ubuntu 16.04
Dependent libraries:
$ ldd /path/to/lib/libsystemc.so
linux-vdso.so.1 => (0x00007ffe29d36000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb9b85f5000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb9b8273000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb9b7f69000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb9b7ba0000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb9b798a000)
/lib64/ld-linux-x86-64.so.2 (0x000056093a23e000)
...to_string[abi:cxx11] ...
One of two things...
First, GCC and Clang are being mixed and matched. If you were compiling with Clang, this would be a likely suspect because of GCC5 and the C++11 ABI and LLVM Issue 23529: Add support for gcc's attribute abi_tag (needed for compatibility with gcc 5's libstdc++).
Second, to_string is C++11, so you need either -std=c++11 or -std=gnu++11. C++11 is the likely candidate if all other things are equal. It also gets you the new ABI unless you -D_GLIBCXX_USE_CXX11_ABI=0.
You could still have problems with dependent library configurations, and they could be surfacing in your question.
I want to use gcc 4.8.1 for my application (requires libstdc++.so.6.0.18), however customers only have libstdc++.so.6.0.13. I have been using -static-libgcc -static-stdlibc++ for a while now, but my application consists of several dynamically linked libraries and one main application. This means that when compiling each dynamic library, they must statically compile the standard library, which is redundant and wasteful. I want to just ship the standard library of my choice with my product, however every time I run my application in an environment like theirs, it always loads the wrong standard library. It prefers the /usr/lib64/ version no matter what I seem to do (it seems to take precedence over LD_LIBRARY_PATH).
Constraints:
I'm not allowed to force them to upgrade to a new standard library.
I don't want to make the dynamic libraries static. (I'd be able to statically compile everything into the main app once, but there are some logistical barriers that prevent me from recompiling some libraries into static ones).
-Wl,-rpath=$(path_to_directory) is a bit dangerous, however it is legal because the customers do source some settings that allow me to set path variables. However, setting the rpath of my new stdlibc++ doesn't seem to be overriding the default /usr/lib64 version. I still get GLIBCXX errors because it won't use the right library.
Surely there is an elegant solution for this?
Perhaps there is just an error in my procedure. Here's an example (sorry about the censor, but it's just username stuff):
~/example$ pwd
/home/username/example
~/example$ echo $LD_LIBRARY_PATH
~/example$ ls
Makefile libstdc++.so.6.0.18 test.cpp
~/example$ make
g++ -std=c++11 -Wall -Werror test.cpp -o test
~/example$ ldd test
./test: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./test)
linux-vdso.so.1 => (0x00007fffe5919000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000390b800000)
libm.so.6 => /lib64/libm.so.6 (0x0000003904800000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000390b400000)
libc.so.6 => /lib64/libc.so.6 (0x0000003904400000)
/lib64/ld-linux-x86-64.so.2 (0x0000003904000000)
~/example$ setenv LD_LIBRARY_PATH /home/username/example
~/example$ echo $LD_LIBRARY_PATH
/home/username/example
~/example$ ldd test
./test: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./test)
linux-vdso.so.1 => (0x00007fff2d3ff000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000390b800000)
libm.so.6 => /lib64/libm.so.6 (0x0000003904800000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000390b400000)
libc.so.6 => /lib64/libc.so.6 (0x0000003904400000)
/lib64/ld-linux-x86-64.so.2 (0x0000003904000000)
Sorry guys, I made a rather dumb mistake...
~/example$ file libstdc++.so.6.0.18
libstdc++.so.6.0.18: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
Some dweeb built the wrong version of the library, and another dweeb (namely myself) tried using it on a 64-bit machine. Using LD_LIBRARY_PATH was working all along...
Your problem is that the executable is linked to the soname libstdc++.so.6 not to the full library filename libstdc++.so.6.0.16. The dynamic linker will look for libstdc++.so.6 in the usual places (i.e. LD_LIBRARY_PATH, DT_RPATH, ldconfig dirs etc.) so to ensure the 6.0.18 version is found you need a symlink called libstdc++.so.6 pointing to it.
Instead of using LD_LIBRARY_PATH (which is fragile on machines you don't control, because users might alter their environment) I prefer linking with '-Wl,-rpath,$ORIGIN' (N.B. the quotes are necessary to stop the shell expanding $ORIGIN)
An RPATH of $ORIGIN tells the dynamic linker to start looking for shared libraries in the same directory as the executable, so if you ship libstdc++.so alongside your executable it will be found. If you want to ship the executable in a bin directory and have the library in a lib directory you can use '-Wl,-rpath,$ORIGIN/../lib' or other paths relative to the location of the executable.
I have been working on a project which will be loaded on an embedded system, has not enough memory/disk space to install a C++ compiler and compile the code, natively.
So, I need to “cross-compile” the code on my development (Host) machine to be used on the target machine (Embedded Linux).
The happening problem related to using strings and iostreams which are a feature of the C++ standard template library (STL). However, because memory is so critical in an embedded system, the standard template library (libstdc++), can not be available on target side.
I need to statistically link the standard libraries on host machine, rather than dynamically link on target side. So, in my Makefile I need to have a slightly complex modification in both compiling and linking steps in order to build my project.
I have used some parameters such as -nodefaultlibs, -static-libstdc++, and -lstdc++ in the linking step and also added -nostdinc++ to the compiler flags. Still, there exist the problem on target side; " can not load library libstdc++.so.6 "
Most of these settings I have tried did not work. Is there any solution?
-lstdc++ overrides -static-libstdc++, try linking with just -static-libstdc++.
See this for example:
$ g++ -o foo foo.cpp -static-libstdc++ -lstdc++
$ ldd foo
linux-gate.so.1 => (0x0056b000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x007ae000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x005dd000)
/lib/ld-linux.so.2 (0x002bc000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x0095e000)
libstdc++ is linked dynamically!
$ g++ -o foo foo.cpp -static-libstdc++
$ ldd foo
linux-gate.so.1 => (0x0097b000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x001f9000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x0037f000)
/lib/ld-linux.so.2 (0x00199000)
now it is not.