How to manually disable libstdc++ in CMake for Clang - c++

Recently I'm configuring a new project in language C and C++ using both CMake and llvm Clang with Visual Studio Code for a program where EVERY exact object or library it generates or depends needs specifying explicitly to make or link against. The program by design should feature high RAM efficency, security for the least vulnerabilities induced by the unused data segments and cross-compilation.
That being said, the provision libraries for architecture, application binary interface (aka ABIs), standard libraries functions from C and C++ standard and executable binary need manual setup for toolchain program to process in appropriate manner.
Well, the libstdc++ substitution with libc++ library is what I think a good "entry point" to kick-off, but definitely not straight forward, which you might have learned enough from documented painful practices elsewhere and think of that as a bad idea...but I'm sorry, this has become my obsession. I really appreciate your help before it drives me nuts here.
Anyway, here is a list of information about my local machine in below:
Ubuntu 20.04 # v5.13.0-40-generic kernel, SMP, x86_64 instruction-set
CMake 3.23.1, built from source
gcc-10:amd64
clang-12:amd64
libstdc++-10-dev:amd64
libc++-12-dev:amd64
Clang works fine to return from command:
jacob.nielson#ubuntu~$: clang++-12 -v -c -xc /dev/null
to keep the new project from any future unexpected and irrelevant issue as much as possible, I leave the project directory layout as simple as it could be before making a CMakeLists.txt:
To begin with, I looked up in CMake's document about either compiling (preprocessing) or linking options:
-"-nostdinc"
-"-nostdinc++"
-"-nobuiltininc"
-"-nostdlib"
-"-nolibc"
-"-nostdlib++"
-"-nodefaultlibs"
Then I come up with a few simple lines in the CMakeLists.txt:
cmake_minimum_required(VERSION 3.23.0)
project(program VERSION 0.0.1)
set(TARGET program)
add_compile_options(-std=c++17)
# I'm not sure about semantics of "-nostdinc++", "-nostdinc" and "-nobuiltininc".
# Should I add them all in case to substitute libstdc++ with libc++ or not in below?
add_compile_options($<$<COMPILE_LANG_AND_ID:CXX,Clang>:-nobuiltininc>)
add_compile_options($<$<COMPILE_LANG_AND_ID:CXX,Clang>:-nostdinc++>)
add_compile_options($<$<COMPILE_LANG_AND_ID:CXX,Clang>:-nostdinc>)
# Should I add path to system headers in "-isystem" option?
# Attention: cmake-generator-expression does not recognize white-space separated options group to be string. It is option "-isystem" where the path to directory as value follows without white-space in this example.
add_compile_options(
$<$<COMPILE_LANG_AND_ID:CXX,Clang>:-isystem/usr/include/x86_64-linux-gnu>
$<$<COMPILE_LANG_AND_ID:CXX,Clang>:-isystem-after/usr/include>
# "-cxx-isystem" option is legacy and is not appropriate for standard headers. Add path to the subdirectories where you put your own c++-only headers in your project.
$<$<COMPILE_LANG_AND_ID:CXX,Clang>:-cxx-isystem ${...}>
)
# If C or/and C++ standard library is turned off like in above, Should I add path to libc++ headers in "-stdlib++-isystem" option?
# Attention: cmake-generator-expression does not recognize white-space separated options group to be string. It is option "-stdlib++-isystem" where the path to directory as value follows without white-space in this example.
add_compile_options($<$<COMPILE_LANG_AND_ID:CXX,Clang>:-stdlib++-isystem/usr/lib/llvm-12/include/c++/v1>)
# Replace default C++ standard with libc++.
add_link_options(
$<$<LINK_LANG_AND_ID:CXX,Clang>:-stdlib=libc++>
)
add_executable(${TARGET} "${CMAKE_CURRENT_SOURCE_DIR}/source/${TARGET}.cpp")
target_link_libraries(${TARGET} PRIVATE
$<$<LINK_LANG_AND_ID:CXX,Clang>:c++>
$<$<LINK_LANG_AND_ID:CXX,Clang>:c++abi>
$<$<LINK_LANG_AND_ID:CXX,Clang>:unwind>
$<$<LINK_LANG_AND_ID:CXX,Clang>:ssl>
$<$<LINK_LANG_AND_ID:CXX,Clang>:crypto>
$<$<LINK_LANG_AND_ID:CXX,Clang>:pthread>
)
Next, I tried to generate "Unix Makefiles" for project:
CMake parsed successfully:
Meanwhile it generates CMakeCCompiler.cmake and CMakeCXXCompiler.cmake in ./build/CMakeFiles/3.23.1/ temporary folder, the later contains a few lines:
set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES "/usr/include/c++/10;/usr/include/x86_64-linux-gnu/c++/10;/usr/include/c++/10/backward;/usr/local/include;/usr/lib/llvm-12/lib/clang/12.0.0/include;/usr/include/x86_64-linux-gnu;/usr/include")
set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "stdc++;m;gcc_s;gcc;c;gcc_s;gcc")
set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/10;/usr/lib/x86_64-linux-gnu;/usr/lib64;/lib/x86_64-linux-gnu;/lib64;/usr/lib;/usr/lib/llvm-12/lib;/lib")
set(CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")
Note: Clang uses heuristic discovery to search headers in directories which are reported by front-end.
This is inappropriate because I just don't want either headers or libraries of libstdc++ to be implicitly used within the project.
Also, it exports compile commands into compile_commands.json as below:
/usr/bin/clang++-12 -DLIBCXXABI_USE_COMPILER_RT=YES -DLIBCXX_USE_COMPILER_RT=YES -I/data/solution/projects/program/include -std=c++17 -stdlib=libc++ -isystem /usr/include/x86_64-linux-gnu -stdlib++-isystem /usr/lib/llvm-12/include/c++/v1 -o CMakeFiles/program.dir/source/program.cpp.o -c /data/solution/projects/program/source/program.cpp
It all looks good. But when I use ldd to check:
jacob.nielson#ubuntu:/data/solution/projects/program/build/debug$ ldd program
linux-vdso.so.1 (0x00007ffee7190000)
libc++.so.1 => /lib/x86_64-linux-gnu/libc++.so.1 (0x00007f69164a5000)
libc++abi.so.1 => /lib/x86_64-linux-gnu/libc++abi.so.1 (0x00007f691646d000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f691628b000) /* LIBSTDC++ in here! */
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f691613c000) /* LIBM in here */
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6916121000) /* gcc startup file in here! */
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6915f2f000) /* LIBC in here! */
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6915f0a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6915f00000)
libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f6915ef6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f691658d000)
It is frustrating to see all libstdc++, libc, libm or libgcc_s remain. Is there any option I missed to link them statically such like -static-libc in GNU CC or do I have to give up my ambition early at this point?

The answer to the question is hereby noted.
There is a mistake about missing definitions to instruct Clang to use compiler_rt. The problem is solved once I had add to relevant options.
As to replace libstsdc++ with libc++, one shall not forget to add the following options:
add_compile_definitions(
$<$<COMPILE_LANG_AND_ID:CXX,Clang>:LLVM_ENABLE_RUNTIMES=libunwind>
$<$<COMPILE_LANG_AND_ID:CXX,Clang>:LIBCXX_USE_COMPILER_RT=YES>
$<$<COMPILE_LANG_AND_ID:CXX,Clang>:LIBCXXABI_USE_COMPILER_RT=YES>
$<$<COMPILE_LANG_AND_ID:CXX,Clang>:LIBUNWIND_USE_COMPILER_RT=YES>
)
add_link_opptions(
$<$<LINK_LANG_AND_ID:CXX,Clang>:-stdlib=libc++>
$<$<LINK_LANG_AND_ID:CXX,Clang>:-rtlib=compiler-rt>
)
AFAK, definitions above help to instruct clang "not to link against default libraries", but one also has to use them in conjunction with compile option "-stdlib=libc++" and especially NO "-nostdlib" for the replace to take effect. Part of the document covers in below:
Compiler runtime
The default runtime library is target-specific. For targets where GCC
is the dominant compiler, Clang currently defaults to using libgcc_s.
On most other targets, compiler-rt is used by default.
However, it is much unclear to me what target refers to here and how comes to tell a compiler is dominant for a given target.

Related

What is the C++/autoconf equivalent to requirements.txt for documenting library requirements?

I have a C++ library that uses autoconf that I have been maintaining for 15 years. I'm now getting it to run with CI and have discovered that I need to do a better job documenting its requirements. With a python program I do this using a file called requirements.txt which is used by setuptools during packaging, and I can also use in the CI system. What's the right way to document this in a C++ autotools package?
This is a kind of question that tech writers would want to know: What packages or dependencies are there of our product.
There's two kinds of dependency in C/C++ as opposed to a singular list of Python dependency (I'm not talking test-specific dependency found in some Python packages or that kind of sort).
There are:
header include dependency
library dependency
Header Include Dependency
There is a C/C++ compiler option that list out all non-system include files:
gcc -c -MMD <source.c>
For all include files:
gcc -c -MD <source.c>
And with those list of include files, you can find out the packages that provides it, for example, in Debian:
dpkg-query -S <include-file.h>
Library Dependencies
Best approach to securing a complete list of libraries used for a particular platform/distro is to use the ldd to extract a list of external object codes that your program requires before it can get up and running.
#!/bin/bash
# List Debian packages that a given executable is dependent on
BINARY_FILE=$1
LIB_LIST=$(ldd $1 | gawk '{ print $1 }' | tr '\n' ' ')
for THIS_LIB in $LIB_LIST; do
dpkg-query -S $THIS_LIB
done
Output result of /bin/ls gives you a multi-platform list of packages that ls executable file depends on:
~/bin/dpkg-dependency-by-executable.sh /bin/ls
dpkg-query: no path found matching pattern *linux-vdso.so.1*
libselinux1:amd64: /lib/x86_64-linux-gnu/libselinux.so.1
libc6-x32: /libx32/libc.so.6
libc6:amd64: /lib/x86_64-linux-gnu/libc.so.6
libc6-i386: /lib32/libc.so.6
libpcre3:amd64: /lib/x86_64-linux-gnu/libpcre.so.3
libpcre3:amd64: /lib/x86_64-linux-gnu/libpcre.so.3.13.3
libc6-i386: /lib32/libdl.so.2
libc6-x32: /libx32/libdl.so.2
libc6:amd64: /lib/x86_64-linux-gnu/libdl.so.2
libc6:amd64: /lib64/ld-linux-x86-64.so.2
libc6-i386: /lib32/libpthread.so.0
libc6-x32: /libx32/libpthread.so.0
libc6:amd64: /lib/x86_64-linux-gnu/libpthread.so.0
root#
With those list, you can ascertain that your autotools has properly make dependency test for them (and often without the system-related ones).

Issues in c++ compilation for embedded system

I have a few related questions about my issues with compilation for embedded system. My questions are not only about HOW to do something, but more about WHY, because I have solutions for my problems (but maybe there are better ones?), but have no idea why some things works in some conditions, and does not work in others. I already spent some time with this, but until yesterday I was doing things a little blindly, with trials and errors, and without knowing what I was doing. Time to stop that! Please, help.
Scenario
I want to develop an application for Xilinx’s Zynq ARM processor, on Zedboard. The app will involve multithreading, some audio manipulation, and httpserver. So I will need pthread, alsa, sndfile and microhttpd libraries. I created rootfs with yocto. In original conf.local file I added/modified these lines:
BB_NUMBER_THREADS ?= "${#oe.utils.cpu_count()}"
PARALLEL_MAKE ?= "-j ${#oe.utils.cpu_count()}"
MACHINE ?= "zedboard-zynq7"
PACKAGE_CLASSES ?= "package_deb"
EXTRA_IMAGE_FEATURES = "debug-tweaks eclipse-debug"
IMAGE_INSTALL_append = "libgcc alsa-utils mpg123 libstdc++ sthttpd libmicrohttpd libsndfile1"
LICENSE_FLAGS_WHITELIST = "commercial_mpg123"
I also had to add some additional layers to bblayers.conf (and of course downloaded them):
meta-xilinx
meta-multimedia (from meta-openembedded)
meta-oe (from meta-openembedded)
meta-webserver (from meta-openembedded)
Lastly, I generated core-image-minimal with bitbake.
This, together with Linux kernel, and other stuff compiled separately, boots and works fine.
Problems
1. Simple app with this rootfs
It is app for Zynq, so I use XSDK, which is SDK from Xilinx, based on Eclipse. I created new Application project. In dialog window I chose Linux as platform, C++ as language, and I provided path to my unpacked rootfs (excactly the one that system boots with, via NFS). My rootfs path is /home/stas/ZedboardPetalinuxFS (it is not Petalinux, I just used to use it, and this folder name is still the same). This sets proper paths for library and headers search in rootfs.
I started with something very simple:
#include <pthread.h>
int main()
{
int i;
i = 1;
return 0;
}
I also added pthread library for linker (in Eclipse settings). Linking command at this point:
arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" -o "test.elf" ./src/main.o -lpthread
At this point it compiles. But it stops, when I add sndfile library
#include <sndfile.h>
This is reasonable, because this rootfs does not have all headers. I need to add another path for searching for headers. So I added path in yocto tmp folder, that has all the headers, that was needed for building rootfs. After I add it, it compiles again successfully. But problems started, when I added sndfile library for linking. Here is linking command and error:
arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" -o "test.elf" ./src/main.o -lpthread -lsndfile
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lsndfile
I looked to usr/lib to check if libsndfile.so is there, and I found only libsndfile.so.1 and ibsndfile.so.1.27. But it is also the case for pthread, and linker does not complain for that. I decided to create libsndfile.so by hand (I linked it to libsndfile.so.1). Linker stopped complaining about it, but started complaining about it’s dependencies. So I also creaded .so files for all the dependencies, and their dependencies, and added them for linking. Then it succeeded. At the end, linking command looked like this:
arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" -o "test.elf" ./src/main.o -lpthread -lvorbisenc -lvorbis -logg -lFLAC -lsndfile
So here goes the first question – why I did not needed .so file for pthread, but needed it for all other libraries? Or more general – when do I need .so file, and when .so.X file is enough?
2. Simple app - another approach
After the first try, I thought I should make another image, this time more suitable for development. Luckily, in Yocto it is quite easy – I just had to modify one line:
EXTRA_IMAGE_FEATURES = "debug-tweaks eclipse-debug dev-pkgs"
dev-pkgs option adds -dev packages for all installed packages.
So now I have rootfs with all needed headers, and .so files pointing where they should.
Before compilation, I removed unnecessary Include path, leaving only the one from rootfs, and removed all the libraries, except pthread, and sndfile. But then I get new errors:
arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" -o "test.elf" ./src/main.o -lsndfile -lpthread
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/libpthread.so.0
makefile:48: polecenia dla obiektu 'test.elf' nie powiodły się (commands for ‘test.elf’ did not succeed)
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find /usr/lib/libpthread_nonshared.a
I spotted, that it looks for libraries in my root folder. Quick search in Google (and SO:)) told me that I should set –-sysroot variable. So I added it to Eclipse option (in Miscelenious card in Linker options) like that:
--sysroot=/home/stas/ZedboardPetalinuxFS
So now linker command looked like this:
arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" --sysroot=/home/stas/ZedboardPetalinuxFS -o "test.elf" ./src/main.o -lsndfile -lpthread
And all succeed! I also wrote simple example that uses pthreads, and sndfile, and it also worked. But WHY? This leads me to second question:
Why do I need --sysroot option in this case? When do I need to use this option in general? And why this time I didn't have to add all the dependencies to linking command?
3. Another idea
At this point, I had an idea, to check what will happen, if I add --sysroot option having rootfs populated with old, non development image. But this gave me new errors:
arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" --sysroot=/home/stas/ZedboardPetalinuxFS -o "test.elf" ./src/main.o -lpthread -lvorbisenc -lvorbis -logg -lFLAC -lsndfile
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find crt1.o: No such file or directory
makefile:48: polecenia dla obiektu 'test.elf' nie powiodły się
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find crti.o: No such file or directory
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lpthread
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lm
So third question – what does this errors mean?
Thanks very much in advance!
"why I did not needed .so file for pthread, but needed it for all
other libraries?"
Actually you do need pthread.so file. You included pthread.h but didn't link with -lpthread. So it's normal you don't see any linker errors.
"when do I need .so file, and when .so.X file is enough"
When you give "-lNAME" parameter to g++, the compiler tells the linker to find libNAME.so within library search paths. Since there may exist multiple versions of the same library(libNAME.so.1, libNAME.so.1.20), *.so files link to desired actual library file. (Versioning of shared objects, ld man pages)
"Why do I need --sysroot option in this case? When do I need to use this option in general? And why this time I didn't have to add all the dependencies to linking command?"
The "dev-pkgs" in EXTRA_IMAGE_FEATURES changes your sysroot implicitly to let you link against the dev packages(yoctoproject image-features). That's why you need -sysroot option. You generally need this option when cross compiling to provide a root for standard search paths for headers and libraries. You didn't need it because you didn't have dev-pkgs image feature that changes your sysroot
"So third question – what does this errors mean?"
Even your the most basic hello world code gets linked with standard c library(if you didn't specify otherwise). libm.so, libpthread.so and crt1.o files are parts of libc library and come with libc dev package. So the linker can't see the standard library directories when it looks from your old sysroot
why I did not needed .so file for pthread, but needed it for all other libraries?
A cross compiler will normally come with a C Runtime (including pthread), typically in a directory that is part of the cross compiler installation.
The linker has built in search paths for libraries. These are in respect to the sysroot, which would by default be set to search the cross compiler's own included target C Runtime. If you added any -L options it would search those first and then move on to these pre-defined directories.
When you linked against pthread it would have found at least libpthread.a in the cross compiler's library directory.
Or more general – when do I need .so file, and when .so.X file is enough?
Shared libraries in Linux typically have a major and a minor version number. Libraries are ABI compatible between different minor versions with the same major version, but not between major versions. Sometimes there are three levels of versions but the principal is similar.
When installing libraries it is common to install the actual file with the full name, eg. libmy.so.1.2, then provide symlinks to libmy.so.1 and libmy.so.
If you are linking an application can work with any library version then you would just specify the name, eg. -lmy. In that case you would need symlinks from libmy.so to libmy.so.1.
If you required a specific version you would put -l:libmy.so.1. The ':' indicates a literal file name.
Linker scripts may affect things and may result in specific versions being selected even when you do specify the short name.
Why do I need --sysroot option in this case? When do I need to use
this option in general?
What --sysroot does is prepend the given path onto all the search directories which would normally be used to search for includes and libraries. It is most useful when cross compiling (as you are doing now) to get the compiler and the linker to search inside the target root instead of the build host's own root.
If you have specified a sysroot you probably do not need to specify include paths via -I or linker paths via -L, assuming that the files are within their normal spots inside your target root.
And why this time I didn't have to add all the dependencies to linking command?
One possible scenario is that the first time, sndfile for statically rather than dynamically linked. This would happen if your first root image had only sndfile.a in the lib dir, or elsewhere on the search path. To then satisfy the requirements of sndfile.a you would also need to link the other libs.
When linking against sndfile.so the dependencies will automatically get loaded via the dynamic linking process.
That's just a working theory at present.
So third question – what does this errors mean?
They mean it cannot find even the C runtime library to link.
As described for the first question, it was previously finding the C runtime in the pre-defined search path (relative to the predefined sysroot) which located the C runtime supplied by the cross compiler.
You disturbed this by supplying your own sysroot. It was now only searching the target root. Since this target root filesystem did not have development libs installed, there was no C runtime there to find.
You are doing several things wrong:
looks like you are not using environment variables, but calling cross-compiler directly. So, instead of compiling with arm-linux-gnueabihf-g++ ..., you should do $CXX .... The CXX is the environment variable set by the yocto script to set environment for cross compilation. Using CXX, you do not need to manually pass --sysroot
You should not link directly to pthread library with -lpthread. You should use -pthread

PCL install links directly to boost installation directory somehow

I have a very odd problem with the installation of PCL. Basically i have set up PCL, boost, cmake, flann etc.. it all builds and compiles correctly. I copied and built the ICP example and it builds just fine.
Here is where it gets weird. When I run the application I get the following error:
ldd:FATAL: Could not load library bin.v2/libs/system/build/qcc-4.4.2/
release/threading-multi/libboost_system.so.1.48.0
So libboost_system.so.1.48.0 exists in the /usr/local/lib path and is even linked earlier by the same application, ie. if i run ldd on the application i get the following linked library information:
$ ldd iterative_closest_point
./iterative_closest_point:
libboost_system.so => /usr/local/lib/libboost_system.so.1.48.0 (0xb8200000)
libboost_filesystem.so => /usr/local/lib/libboost_filesystem.so.1.48.0 (0xb8209000)
libboost_thread.so => /usr/local/lib/libboost_thread.so.1.48.0 (0xb8225000)
OTHER BOOST
libpcl_common.so.1.7 => /usr/local/lib/libpcl_common.so.1.7.1 (0xb82ea000)
libpcl_octree.so.1.7 => /usr/local/lib/libpcl_octree.so.1.7.1 (0xb838c000)
OTHER PCL
libstdc++.so.6 => /usr/qnx650/target/qnx6/x86/lib/libstdc++.so.6.0.13 (0xb9285000)
libm.so.2 => /usr/qnx650/target/qnx6/x86/lib/libm.so.2 (0xb8774000)
libc.so.3 => /usr/lib/ldqnx.so.2 (0xb0300000)
ldd:FATAL: Could not load library bin.v2/libs/system/build/qcc-4.4.2/release/threading-multi/libboost_system.so.1.48.0
So I did some investigation into what the hell PCL is looking for, what is bin.v2? It exists in the boost install directory????
Now here is where it just gets nuts, if i run the program with an absolute path from the boost install directory ie. where the bin.v2 folder exists:
qnx:/root/boost/boost_1_48_0# /root/experiments/checkPCL/iterative_closest_point
it works!! the program outputs the desired things. So i was like alright, lets run ldd here:
qnx:/root/boost/boost_1_48_0# ldd /root/experiments/checkPCL/iterative_closest_point
and we get this:
libboost_system.so => /usr/local/lib/libboost_system.so.1.48.0 (0xb8200000)
MORE BOOST
libpcl_common.so.1.7 => /usr/local/lib/libpcl_common.so.1.7.1 (0xb82ea000)
MORE PCL
libstdc++.so.6 => /usr/qnx650/target/qnx6/x86/lib/libstdc++.so.6.0.13 (0xb9285000)
libm.so.2 => /usr/qnx650/target/qnx6/x86/lib/libm.so.2 (0xb8774000)
libc.so.3 => /usr/lib/ldqnx.so.2 (0xb0300000)
libboost_system.so.1.48.0 => /root/SMG/extern/libs/boost/boost_1_48_0/bin.v2/libs/system/build/qcc-4.4.2/release/threading-multi/libboost_system.so.1.48.0 (0xb87a7000)
libbz2.so.1.0.4 => /usr/lib/libbz2.so.1.0.4 (0xb87b0000)
libz.so.2 => /proc/boot/libz.so.2 (0xb87c2000)
The big long one is an absolute link into the boost filepath. I dont understand how PCL or ldd or anything could know about this path.
Does anyone have any ideas about how this could have happened? Also I need some solutions on how to fix it.
EDIT + ADD:
So recently, i am not sure what has changed but i have started to get the linker warning (not error):
/usr/qnx650/host/qnx6/x86/usr/bin/ntox86-ld: warning: bin.v2/libs/system/build/
qcc-4.4.2/release/threading-multi/libboost_system.so.1.48.0, needed by
/usr/local/lib/libboost_filesystem.so, not found (try using -rpath or -rpath-link)
so for whatever reason this is definitely attempting to link to bin.v2/.../... which is absolutely nuts, i have never seen this before? I have now scoured the boost install directory looking for things that might caused this. Nothing is unusual about how boost is installed.
As a further note i have made a simple example, a program that has main, includes and prints "it works", it has the following CMakeLists.txt:
find_package(PCL 1.2 REQUIRED)
find_package(Boost 1.48.0 COMPONENTS system filesystem REQUIRED)
add_executable (test test.cpp)
target_link_libraries(test
${BOOST_FILESYSTEM} #Works
${PCL_DEFINITIONS} #Works
${PCL_SEARCH_LIBRARIES} #If i add this it fails!
)
So it seems like PCL and boost are interacting badly and causing some truly crazy behavior!
This may not be of help but I have the same problem and here is what I found. That path is used by some boost libraries.
objdump -x libbost_filesystem-qcc-mt-1_55.so will show:
Dynamic Section:
NEEDED bin.v2/libs/system/build/qcc/release/threading-multi/libboost_system-qcc-mt-1_55.so.1.55.0
NEEDED libm.so.2
NEEDED libstdc++.so.6
NEEDED libc.so.3
INIT 0x00004d40
Notice the full path.
I came upon this post while looking for a solution to this problem. I'm pretty sure it's a boost build related issue though, I'm also using QNX.
If it works from the absolute directory that contains bin.v2/libs/system/build/qcc-4.4.2/release/threading-multi/ then probably you have
set LD_LIBRARY_PATH set to include . (the current working directory)
added the current work directory using ldconfig somehow (there's several ways)
This is a bad idea in general. It's especially a bad idea if you're running as root (which it seems you do) because it can be exploited as a security hole.
The real issue would still appear to be that the linker embeds the full path for libboost_system. I don't know what causes this, but perhaps
you specify the library as a concrete source (libboost_system.so.1.48.0 in stead of -lboost_system on most linkers/compilers)
it is some kind of linker option (like -rpath?)
Hope this helps

Version numbers in shared object files

I'm building a shared object file from a group of C++ source files using GCC. All the example tutorials on building .so files show the file created with a version number after the .so suffix. For example:
gcc -shared -Wl,-soname,libmean.so.1 -o libmean.so.1.0.1 calc_mean.o
This would produce the .so file libmean.so.1.0.1
Additionally, if I browse the /usr/lib directory on my local machine, I see that many of the .so files have version numbers at the end.
However, when I compile a shared object file and place it in /usr/lib, the linker is unable to find it if I put a version number at the end. If I remove the version number, it works fine. I really don't care about putting a version number or not, I just don't understand why this seems to be a common convention, and yet this causes the shared library to not work with the linker. So, what's going on here? Why is there a convention to place the version number at the end of an .so file name?
The version number is appended so you can have multiple incompatible library versions coexisting in the system. You should increment the major version number (the number in soname) every time you change the API in an incompatible way (assuming the previous version is installed and used in the system, of course).
The 2nd and 3rd numbers in the file name allows for multiple minor revisions of the library in the system, switchable system-wide with a simple symlink update.
At link time you can give the .so file name as a linker argument, instead of -l option. ldd is smart enough to extract the soname from it, the binary linked this way uses it to find the library.
For example, let's compile the library and test binary using it:
czajnik#czajnik:~/z$ gcc -shared -Wl,-soname,libtest.so.2 -o libtest.so.2.3.4 a.c
czajnik#czajnik:~/z$ gcc -o test b.c -L. ./libtest.so.2.3.4
You can use ldd to verify, that the binary now looks for libtest.so.2:
czajnik#czajnik:~/z$ LD_LIBRARY_PATH=. ldd ./test
linux-gate.so.1 => (0x002c1000)
libtest.so.2 => not found
libc.so.6 => /lib/libc.so.6 (0x00446000)
/lib/ld-linux.so.2 (0x00a28000)
It obviously can't find it, but that's what the symlink is for:
czajnik#czajnik:~/z$ ln -s libtest.so.2.3.4 libtest.so.2
czajnik#czajnik:~/z$ LD_LIBRARY_PATH=. ldd ./test
linux-gate.so.1 => (0x00d75000)
libtest.so.2 => ./libtest.so.2 (0x00e31000)
libc.so.6 => /lib/libc.so.6 (0x00a5e000)
/lib/ld-linux.so.2 (0x00378000)
Update: All of the above is true, yet I wasn't myself aware of the meaning of the 3rd component of the version number. Until recently, I believed it is simply a patch number (or similar thing). Wrong! For libtool it has a special meaning.
The 3rd component turned out to be age field, which says how many major versions are backward compatible with the current one.
Recommended reading:
Idiot's Guide to ABI Versioning
Libtool's versioning system

How do I get rid of LD_LIBRARY_PATH at run-time?

I am building a C++ application that uses Intel's IPP library. This library is installed by default in /opt and requires you to set LD_LIBRARY_PATH both for compiling and for running your software (if you choose the shared library linking, which I did). I already modified my configure.ac/Makefile.am so that I do not need to set that variable when compiling, but I still can't find the shared library at run-time; how do I do that?
I'm compiling with the -Wl, -R/path/to/libdir flag using g++
Update 1:
Actually my binary program has some IPP libraries correctly linked, but just one is not:
$ ldd myprogram
linux-vdso.so.1 => (0x00007fffa93ff000)
libippacem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippacem64t.so.6.0 (0x00007f22c2fa3000)
libippsem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippsem64t.so.6.0 (0x00007f22c2d20000)
libippcoreem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippcoreem64t.so.6.0 (0x00007f22c2c14000)
[...]
libiomp5.so => not found
libiomp5.so => not found
libiomp5.so => not found
Of course the library is there:
$ locate libiomp5.so
/opt/intel/ipp/6.0.2.076/em64t/sharedlib/libiomp5.so
By /path/to/lib do you mean path to the directory containing the library, or the path to the actual file?
The -R option given a directory argument is treated like -rpath by ld, which is the option you're actually wanting here. It adds the given directory to the runtime library search path. That should work, as long as you give it the directory and not filename. I'm fairly confident about that, having done it myself, and because it's one of the hints given by libtool:
Libraries have been installed in:
/path/to/library-directory
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
use the `-Wl,-rpath -Wl,LIBDIR' linker flag
have your system administrator add LIBDIR to `/etc/ld.so.conf'
(I paste this here since conceivably one of the other options could be more desirable - for example LD_RUN_PATH can save you makefile modification)
As suggested by Richard Pennington, the missing library is not used directly by my application, but it is used by the shared libraries I use. Since I cannot recompile IPP, the solution to my problem is to add -liomp5 when compiling, using the -R option for the linker. This actually adds the rpath for libiomp5.so fixing the problem!
You can check if the path to the library is being picked up from your -R flag by running the ldd command or the readelf command on your binary. The LD_LIBRARY_PATH environment variable is an override, so shouldn't be necessary normally.
You should use the -R option if possible.
If not, rename your executable and create a launch script that runs your executable, and in there set LD_LIBRARY_PATH just for that scope.
Depending on platform, you can modify ld.so.conf via /etc/ld.so.conf.d (Redhat/Fedora come to mind) which makes deploying changes to ld.so "easier" from a deployment scenario.
Besides all the useful hints posted here.. you're not trying to use a 64-bit specific library on a 32-bit system (or viceversa, depending on other conditions), are you?
bash:
export LD_LIBRARY_PATH=/path/to/lib
tcsh:
setenv LD_LIBRARY_PATH /path/to/lib
Try configuring your ldconfig through ld.so.conf so it searches your /opt/... directory by default.