Downloaded boost 1.66, unbzipped, launching bootstrap:
Bootstrapping is done. To build, run:
./b2
b2 reports:
...blablabla..
- zlib : yes (cached)
- bzip2 : yes (cached)
...blablabla..
The following directory should be added to linker library paths:
/home/steve/boost_1_66_0/stage/lib
...blablabla..
No errors during build, only warnings. I am looking into /home/steve/boost_1_66_0/stage/lib, but there is no files with bz in their name. On windows prebuilt binaries I have:
boost_bzip2-vc140-mt-gd-x64-1_66.dll
boost_bzip2-vc140-mt-gd-x64-1_66.lib
boost_bzip2-vc140-mt-x64-1_66.dll
boost_bzip2-vc140-mt-x64-1_66.lib
As a result my project builds fine on Windows and fails on Linux because of missing bz2 dependencies. Any ideas?
My linux is ubuntu 14.
Thanx.
Any ideas?
Yup. You're looking for ghosts. On linux, libz and libbz2 are the packaged versions by default:
cd custom/boost_1.66.0/
ldd ldd stage/lib/libboost_iostreams.so.1.66.0
Prints
linux-vdso.so.1 => (0x00007fffe9708000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc3399af000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fc33979f000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fc33957d000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc3391f5000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc338fde000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc338dc1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc3389f7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc3387f3000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc3384ea000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc339de5000)
The library is part of the ``libbz2-1.0` package as you can find with
dpkg --search /lib/x86_64-linux-gnu/libbz2.so.1.0
libbz2-1.0:amd64: /lib/x86_64-linux-gnu/libbz2.so.1.0
So if you want to build boost with bzip2 support, make sure you installed the development pacakage:
sudo apt install libbz2-dev
In fact, I'm often "lazy" and just install the dependencies from the distro boost packages:
sudo apt build-dep libboost-all-dev
It looks like you got that part covered, so you were looking for "extra libraries" that donot exist.
Ok, what I've found out is that on Linux and Windows you need different libraries for bz2 streams to function. I am using cmake and this is how I've solved it:
if (MSVC)
find_package(Boost COMPONENTS system filesystem bzip2 REQUIRED)
endif()
if(LINUX)
find_package(Boost COMPONENTS system filesystem iostreams REQUIRED)
endif()
otherwise linker produces errors both on Windows and Linux.
Related
This is centos system. I has installed intel HPC toolkit(toolkit before intel oneAPI, including intel c++/c/fortran/MKL...). Then after I remove the intel toolkit, my g++ didn't work(so does my gcc, same error). It seems the g++ is looking for intel math library. Since I removed the intel toolkit, it can not find the intel math library and complain error.
How can I tell g++ do not to find intel math library? And how can I know what library g++ are looking for?
Thank you for your help!
The c++ example
#include<iostream> #include<cmath>
int main(){
int a = 1<<31;
std::cout<<"a is "<< a <<std::endl;
int b = std::abs(a);
std::cout<<"b is "<< b <<std::endl;
return 0;
}
the command I used to compile the c++ example
g++ a.cpp
the error it complain
/usr/local/gcc/10.1.0/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/cc1plus: error while loading shared libraries: libsvml.so: cannot open shared object file: No such file or directory
LDD result: for my gcc
(base) [Js#XiaoXin13pro ~]$ ldd /usr/local/gcc/10.1.0/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/cc1plus
linux-vdso.so.1 => (0x00007fffffad5000)
libisl.so.15 => /usr/local/lib/libisl.so.15 (0x00007f111d980000)
libmpc.so.3 => /usr/local/lib/libmpc.so.3 (0x00007f111d760000)
libmpfr.so.4 => /usr/local/lib/libmpfr.so.4 (0x00007f111d4f0000)
libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x00007f111d260000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f111d040000)
libm.so.6 => /lib64/libm.so.6 (0x00007f111cd30000)
libc.so.6 => /lib64/libc.so.6 (0x00007f111c960000)
/lib64/ld-linux-x86-64.so.2 (0x00007f111de00000)
libimf.so => /lib64/libimf.so (0x00007f111c490000)
libsvml.so => not found
libirng.so => not found
libgcc_s.so.1 => /usr/local/gcc/10.1.0/lib64/libgcc_s.so.1 (0x00007f111c260000)
libintlc.so.5 => not found
libsvml.so => not found
libirng.so => not found
libintlc.so.5 => not found
libsvml.so => not found
libirng.so => not found
libintlc.so.5 => not found
libsvml.so => not found
libirng.so => not found
libintlc.so.5 => not found
libintlc.so.5 => not found
LDD result: for system gcc
(base) [Js#XiaoXin13pro ~]$ ldd /usr/libexec/gcc/x86_64-redhat-linux/4.8.5/cc1plus
linux-vdso.so.1 => (0x00007fffea241000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f225a4e0000)
libmpc.so.3 => /usr/local/lib/libmpc.so.3 (0x00007f225a2c0000)
libmpfr.so.4 => /usr/local/lib/libmpfr.so.4 (0x00007f225a050000)
libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x00007f2259dc0000)
libz.so.1 => /lib64/libz.so.1 (0x00007f2259b90000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2259880000)
libc.so.6 => /lib64/libc.so.6 (0x00007f22594b0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f225a800000)
libimf.so => /lib64/libimf.so (0x00007f2258fe0000)
libsvml.so => not found
libirng.so => not found
libgcc_s.so.1 => /usr/local/gcc/10.1.0/lib64/libgcc_s.so.1 (0x00007f2258db0000)
libintlc.so.5 => not found
libsvml.so => not found
libirng.so => not found
libintlc.so.5 => not found
libsvml.so => not found
libirng.so => not found
libintlc.so.5 => not found
libintlc.so.5 => not found
update gcc using scl:
sudo yum install centos-release-scl
sudo yum install devtoolset-8-gcc*
scl enable devtoolset-8 bash
check gcc
(base) [Js#XiaoXin13pro ~]$ which gcc
/opt/rh/devtoolset-8/root/usr/bin/gcc
(base) [Js#XiaoXin13pro ~]$ gcc --version
gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and still complain
(base) [Js#XiaoXin13pro ~]$ g++ a.cpp
/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/cc1plus: error while loading shared libraries: libsvml.so: cannot open shared object file: No such file or directory
and ldd result
(base) [Js#XiaoXin13pro ~]$ ldd /opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/cc1plus
linux-vdso.so.1 => (0x00007ffff5a56000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fe19add0000)
libmpc.so.3 => /usr/local/lib/libmpc.so.3 (0x00007fe19abb0000)
libmpfr.so.4 => /usr/local/lib/libmpfr.so.4 (0x00007fe19a940000)
libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x00007fe19a6b0000)
libz.so.1 => /lib64/libz.so.1 (0x00007fe19a480000)
libm.so.6 => /lib64/libm.so.6 (0x00007fe19a170000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe199da0000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe19b000000)
libimf.so => /lib64/libimf.so (0x00007fe1998d0000)
libsvml.so => not found
libirng.so => not found
libgcc_s.so.1 => /usr/local/gcc/10.1.0/lib64/libgcc_s.so.1 (0x00007fe1996a0000)
libintlc.so.5 => not found
libsvml.so => not found
libirng.so => not found
libintlc.so.5 => not found
libsvml.so => not found
libirng.so => not found
libintlc.so.5 => not found
libintlc.so.5 => not found
I find someone encountered the same error. It's shown in here
Install OpenMPI from repository with GCC instead of Intel.
Why gcc is looking for the intel math library? In my exampl, it seems mpc\mpfr\gmp in /usr/local/lib depends on the Intel library.
I searched these three library in other path but found nothing. I removed these three library and reinstalled gcc by sudo yum install gcc. And this time it works fine.
The last time I reinstalled gcc and failed, because yum find these three library in /usr/local/lib and didn't reinstall them. So the reinstalled gcc that depends on the library still will search for Intel math library. And this time since the library in /usr/local/lib is removed, yum install these three library that don't depend on Intel math library. So gcc don't search for intel math library anymore.
I guess maybe these libraries in /usr/local/lib is installed when I install my gcc10 and that time Intel library is still in there, so these libraries are builed with intel and depend on intel library.
By the way, this post explains what is mpc\mpfr\gmp :
GCC depends on:
GMP: GNU Multiple Precision Arithmetic Library
MPFR: GNU Multiple-precision floating-point rounding library
MPC: GNU Multiple-precision C library
ELF: Executable and Linkable Format library
PPL: Parma Polyhedra Library (optional, for memory optimizations)
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'm building a dynamic library on Ubuntu 14.04.5, that depends on some static libraries (Boost and OpenSSL).
If I use this library in a project on another Ubuntu machine, it works perfectly. However, if I build it and use it in a project on an Arch machine (Antergos), it says the following during the build process:
main.cpp.o: In function `init()':
main.cpp:(.text+0xf8): undefined reference to `Util::generateString[abi:cxx11](int)'
I'm building my project with the following:
g++ -Ldeps -Ideps/include main.cpp -lmylib
deps contains libmylib.so and the required header files in deps/include.
If I run ldd on my mylib.so on Ubuntu, I get the following:
linux-vdso.so.1 => (0x00007ffdd24cf000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f10b2f97000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f10b2c91000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f10b2a73000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f10b26ab000)
/lib64/ld-linux-x86-64.so.2 (0x00007f10b3ff3000)
If I run ldd on mylib.so on Antergos, I get the following:
linux-vdso.so.1 (0x00007ffcce115000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f5a42fef000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f5a42cdc000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f5a42abe000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f5a4271a000)
/usr/lib64/ld-linux-x86-64.so.2 (0x000055ced49a7000)
I'm probably missing something easy, but I can't seem to get it to work. What am I doing wrong?
I'm assuming that Util::generateString[abi:cxx11](int) is a function exported by your libmylib.so library? If so, you may want to recompile that library first and then reattempt the compilation/linking of main.cpp.
I suggest this to ensure that the c++ standard library that each component is linked against is the same version. It looks like libmylib.so was compiled against the c++11 standard library, you'll want to ensure main.cpp matches that. You can always specify which one you're linking against using --std= option (e.g. --std=c++11, --std=c++0x, --std=c++17).
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'm working though the First Steps tutorial on the POCO Project site, and I've successfully built the library (Debian Linux, 2.6.26, gcc 4.3.2) under my home directory
~/Development/POCO
with the shared libraries located in
~/Development/POCO/lib/Linux/x86_64/lib
My problem is that any application I build that depends on these libraries can only be run from the shared library directory.
~/Development/POCO/lib/Linux/x86_64$ ldd ~/Development/Cloud/DateTimeSample/bin/Linux/x86_64/DateTime
linux-vdso.so.1 => (0x00007fffe69fe000)
libPocoFoundation.so.6 (0x00007fa8de44f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fa8de233000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fa8de02f000)
librt.so.1 => /lib/librt.so.1 (0x00007fa8dde26000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa8ddb1a000)
libm.so.6 => /lib/libm.so.6 (0x00007fa8dd897000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fa8dd680000)
libc.so.6 => /lib/libc.so.6 (0x00007fa8dd32d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa8de7e0000)
And running DateTime from this directory would work as you would expect. However
~/Development/Cloud/DateTimeSample/bin/Linux/x86_64$ ldd DateTime
linux-vdso.so.1 => (0x00007fff24dfe000)
libPocoFoundation.so.6 => not found
libpthread.so.0 => /lib/libpthread.so.0 (0x00007ffc1c7dd000)
libdl.so.2 => /lib/libdl.so.2 (0x00007ffc1c5d9000)
librt.so.1 => /lib/librt.so.1 (0x00007ffc1c3d0000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ffc1c0c4000)
libm.so.6 => /lib/libm.so.6 (0x00007ffc1be41000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007ffc1bc2a000)
libc.so.6 => /lib/libc.so.6 (0x00007ffc1b8d7000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffc1c9f9000)
so running the executable from any other directory results in
error while loading shared libraries: libPocoFoundation.so.6: cannot open shared object file: No such file or directory
Looking at the output from the make process, the directory is correctly specified
g++ [blah] -L/home/npalko/Development/POCO/lib/Linux/x86_64
-lPocoFoundation
I've tried setting LD_LIBRARY_PATH to /home/npalko/Development/POCO/lib/Linux/x86_64, but it has not changed anything. Any help would be greatly appreciated!
If you don't want to have to deal with the LD_LIBRARY_PATH variable, you can add the linker -rpath option to the gcc command line. In your case, this would be:
gcc ... -Wl,-rpath=/home/npalko/Development/POCO/lib/Linux/x86_64
This effectively hardcodes that path in the executable, so it may or may not be suitable for your purposes.
This fails?
LD_LIBRARY_PATH=/home/npalko/Development/POCO/lib/Linux/x86_64 ~/Development/Cloud/DateTimeSample/bin/Linux/x86_64/DateTime
Just thought you may not be setting LD_LIBRARY_PATH properly
And this?
ls -alh /home/npalko/Development/POCO/lib/Linux/x86_64/libPocoFoundation.so
If both fail I can't see a reason.
You must specify to the linker the path of your library
g++ [blah] -Wl,-rpath=/home/npalko/Development/POCO/lib/Linux/x86_64
-Wl means your pass an option to the linker
-rpath is the linker option
Add a directory to the runtime library search path. This is used
when linking an ELF executable with shared objects. All -rpath
arguments are concatenated and passed to the runtime linker, which
uses them to locate shared objects at runtime. The -rpath option
is also used when locating shared objects which are needed by
shared objects explicitly included in the link;