Hello I'm a newbie in compiling shared libraries.
My shared library depends on curl, ssl and crypto.
I've compiled the libcurl and the output libraries are:
libcurl.so.4 --> libcurl.so.4.3.0
libcurl.so.4.3.0
and I've compiled my shared library using the following command:
g++ -m32 -shared \
-o libtestshared.so.1 \
-fPIC ../build/*.o \
-lpthread \
../openssl/lib/libssl.so.1.0.0 \
../openssl/lib/libcrypto.so.1.0.0 \
../curl/lib/libcurl.so.4.3.0
But when I figure out what are the libraries my library depends on, I found:
ldd libtestshared.so.1
linux-gate.so.1 => (0x00e2a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00aec000)
libssl.so.1.0.0 => /home/usr1/openssl/lib/libssl.so.1.0.0 (0x0034c000)
libcrypto.so.1.0.0 => /home/usr1/openssl/lib/libcrypto.so.1.0.0 (0x003a8000)
libcurl.so.4 => /home/usr1/curl/lib/libcurl.so.4 (0x001cf000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00229000)
libm.so.6 => /lib/libm.so.6 (0x006be000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00eaf000)
libc.so.6 => /lib/libc.so.6 (0x006e8000)
/lib/ld-linux.so.2 (0x0055e000)
libdl.so.2 => /lib/libdl.so.2 (0x001ba000)
librt.so.1 => /lib/librt.so.1 (0x00314000)
Why only libcurl is refereing to the symbolic link?
Related
I have a shared library in linux that was compiled using glibc and I want to run it in Alpine linux without recompiling it against Alpaine C libraries.
I found that there is solution to install gcompat - which is wrapper to Alpine C library to glibc and than with
patchelf --add-needed libgcompat.so.0 /var/lib/libdyn_MyLib.so
I can add the gcompat library into the my own library without compilation and it will tell the dynamic loader to look for symbols also in libgcompat.so
It worked partially and the ldd output of the shared library is:
ldd /var/lib/libdyn_MyLib.so
/lib/ld-musl-x86_64.so.1 (0x7f79007cc000)
libgcompat.so.0 => /lib/libgcompat.so.0 (0x7f78ff278000)
libicudata.so.50 => /lib/libicudata.so.50 (0x7f78fdca4000)
libicui18n.so.50 => /lib/libicui18n.so.50 (0x7f78fd8a6000)
libicuuc.so.50 => /lib/libicuuc.so.50 (0x7f78fd52d000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f78fd2df000)
libm.so.6 => /lib/ld-musl-x86_64.so.1 (0x7f79007cc000)
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7f78fd298000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f78fd27a000)
libpthread.so.0 => /lib/ld-musl-x86_64.so.1 (0x7f79007cc000)
libc.so.6 => /lib/ld-musl-x86_64.so.1 (0x7f79007cc000)
ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x7f78fd274000)
libucontext.so.1 => /lib/libucontext.so.1 (0x7f78fd26f000)
libobstack.so.1 => /usr/lib/libobstack.so.1 (0x7f78fd26a000)
libdl.so.2 => /lib/ld-musl-x86_64.so.1 (0x7f79007cc000)
Error relocating libdyn_MyLib.so: feenableexcept: symbol not found
I can see that libgcompat.so is listed and there are no "not found" libraries.
All the "symbol not found" disappeared except for "feenableexecpt".
After referring to documentation, feenableexecpt is extension of glibc and not supported in gcompat package and I can understand why it's hard to support it.
I want to ignore this function call so I tried to implement "feenableexecpt" that does nothing and add this library to libdyn_MyLib.so (like implementing my own feenableexecpt that does nothing as they implement glibc library using different library).
Here is my code:
glibc_extension.h:
#ifndef __ALPINE_GLIBC__
#define __ALPINE_GLIBC__
extern int feenableexcept(int __excepts) throw ();
#endif
lib_ext.cpp:
#include "glibc_extension.h"
int feenableexcept(int e) throw () {
return 0;
}
complied it as share library:
gcc -Wall -Werror -shared -o libalpine.so lib_ext.cpp
I can see feenableexecpt in the symbols table using nm.
I had also used patchelf to add this library to my shared library, here is the output of the shared library again:
ldd /var/lib/libdyn_MyLib.so
/lib/ld-musl-x86_64.so.1 (0x7f79007cc000)
libalpine.so => /lib/libalpine.so (0x7f78ff28b000)
libgcompat.so.0 => /lib/libgcompat.so.0 (0x7f78ff278000)
libicudata.so.50 => /lib/libicudata.so.50 (0x7f78fdca4000)
libicui18n.so.50 => /lib/libicui18n.so.50 (0x7f78fd8a6000)
libicuuc.so.50 => /lib/libicuuc.so.50 (0x7f78fd52d000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f78fd2df000)
libm.so.6 => /lib/ld-musl-x86_64.so.1 (0x7f79007cc000)
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7f78fd298000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f78fd27a000)
libpthread.so.0 => /lib/ld-musl-x86_64.so.1 (0x7f79007cc000)
libc.so.6 => /lib/ld-musl-x86_64.so.1 (0x7f79007cc000)
ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x7f78fd274000)
libucontext.so.1 => /lib/libucontext.so.1 (0x7f78fd26f000)
libobstack.so.1 => /usr/lib/libobstack.so.1 (0x7f78fd26a000)
libdl.so.2 => /lib/ld-musl-x86_64.so.1 (0x7f79007cc000)
Error relocating libdyn_MyLib.so: feenableexcept: symbol not found
I can see libalpaine.so in the ldd output but still "feenableexecpt" is missing.
What have I done wrong?
Thanks
I was expecting the feenableexecpt symbol to be found by the dynamic program executer.
I build an R package which uses Rcpp and links to a third-party shared object (libbarraopt.so) (which also links to other shared objects such as liboptsrvr.so in its own directory). To ensure that it is able to find those shared objects it links against, I put the following variables in ~/.Renviron:
BARRA_OPS_HOME=${HOME}/bin/BarraOptimizer8.5
In the package, I create the following src/Makevars:
BARRA_LIB=$(BARRA_OPS_HOME)/lib/intel64
BARRA_INCLUDE=$(BARRA_OPS_HOME)/include
PKG_CXXFLAGS=-I$(BARRA_INCLUDE)
PKG_CFLAGS=-I$(BARRA_INCLUDE)
PKG_LIBS=-L$(BARRA_LIB) -Wl,-R,$(BARRA_LIB) -lbarraopt
Under Ubuntu 16.04, I can build, load, and use the package successfully without any problem. However, when I test exactly the same package when OS is upgraded to 17.10, the package can be built but it cannot be loaded, saying:
g++ -std=gnu++11 -I/usr/share/R/include -DNDEBUG -I"/home/renkun/R/x86_64-pc-linux-gnu-library/3.4/Rcpp/include" -I/home/renkun/bin/BarraOptimizer8.5/include -fpic -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c RcppExports.cpp -o RcppExports.o
** libs
g++ -std=gnu++11 -I/usr/share/R/include -DNDEBUG -I"/home/renkun/R/x86_64-pc-linux-gnu-library/3.4/Rcpp/include" -I/home/renkun/bin/BarraOptimizer8.5/include -fpic -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c barraopt.cpp -o barraopt.o
g++ -std=gnu++11 -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -Wl,-z,relro -o barraopt.so RcppExports.o barraopt.o -L/home/renkun/bin/BarraOptimizer8.5/lib/intel64 -Wl,-R,/home/renkun/bin/BarraOptimizer8.5/lib/intel64 -lbarraopt -L/usr/lib/R/lib -lR
installing to /tmp/Rtmpvbb6Io/devtools_install_42a342a07f84/barraopt/libs
* DONE (barraopt)
Error in dyn.load(dllfile) :
unable to load shared object '/home/renkun/Workspaces/barraopt/src/barraopt.so':
liboptsrvr.so: cannot open shared object file: No such file or directory
Calls: suppressPackageStartupMessages ... <Anonymous> -> load_all -> load_dll -> library.dynam2 -> dyn.load
Execution halted
Exited with status 1.
It seems that -Wl,-rpath is not effective here.
Under a machine with Ubuntu 16.04, ldd src/barraopt.so shows that all dynamic linking is corrected resolved. (BARRA_OPS_HOME = /home/ken/bin/BarraOptimizer8.5)
linux-vdso.so.1 => (0x00007ffc89a16000)
libbarraopt.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libbarraopt.so (0x00007f85dae49000)
libimf.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libimf.so (0x00007f85da97f000)
libR.so => /usr/lib/libR.so (0x00007f85da346000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f85d9fc4000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f85d9dae000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f85d99e3000)
liboptsrvr.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/liboptsrvr.so (0x00007f85d7b10000)
libopsproto.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libopsproto.so (0x00007f85d77a1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f85d7497000)
libintlc.so.5 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libintlc.so.5 (0x00007f85d7249000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f85d6fe8000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f85d6da1000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f85d6b31000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f85d690f000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f85d66fe000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f85d64e4000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f85d62dc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f85d60d7000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f85d5eb5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f85d5c98000)
/lib64/ld-linux-x86-64.so.2 (0x000055fb75088000)
libifcore.so.5 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libifcore.so.5 (0x00007f85d5961000)
libifport.so.5 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libifport.so.5 (0x00007f85d5732000)
libsvml.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libsvml.so (0x00007f85d4e6d000)
libmosek64.so.7.0 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libmosek64.so.7.0 (0x00007f85d3c63000)
libiomp5.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libiomp5.so (0x00007f85d396b000)
libprotobuf.so.6 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libprotobuf.so.6 (0x00007f85d3668000)
libbridge_common.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libbridge_common.so (0x00007f85d3417000)
libsharc_xmlxproto.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libsharc_xmlxproto.so (0x00007f85d31a4000)
libboost_thread.so.1.49.0 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libboost_thread.so.1.49.0 (0x00007f85d2f8a000)
libopenblas.so.0 => /usr/lib/libopenblas.so.0 (0x00007f85d0ef5000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f85d0ccc000)
libxerces-c-3.1.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libxerces-c-3.1.so (0x00007f85d07c4000)
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f85d0499000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f85d027f000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f85d0040000)
However, with the same source, under Ubuntu 17.10, ldd shows that the shared objects libbarraopt.so links against are not resolved even though -Wl,-rpath is secified: (BARRA_OPS_HOME = /home/renkun/bin/BarraOptimizer8.5)
linux-vdso.so.1 => (0x00007ffe067f5000)
libbarraopt.so => /home/renkun/bin/BarraOptimizer8.5/lib/intel64/libbarraopt.so (0x00007f3dc5f0c000)
libR.so => /usr/lib/libR.so (0x00007f3dc58e4000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3dc555e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3dc5208000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3dc4ff1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3dc4c11000)
liboptsrvr.so => not found
libopsproto.so => not found
libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f3dc49b6000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f3dc4770000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f3dc44fe000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f3dc42d8000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f3dc40c8000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3dc3eab000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3dc3ca3000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3dc3a9f000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f3dc3870000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3dc3651000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3dc6526000)
libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 (0x00007f3dc13ab000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f3dc1182000)
libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f3dc0da3000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f3dc0b63000)
It looks like only libbarraopt.so is linked with the correct path but shared objects it links against are missing.
I'm wondering what might be wrong with my build configurations that breaks under the toolchain shipped by 17.10. Although using global config such as ldconfig would solve such problem, I prefer not because some .so it relies have conflict with the version the OS ships. I'd rather use a locally configured version without affecting the global config.
It seems that -Wl,-rpath is not effective here.
What likely happened is that your updated linker emits DT_RUNPATH dynamic tag, where the old linker emitted DT_RPATH. (It's also possible that your old linker was GNU-ld, and the new one is Gold.)
The DT_RUNPATH is preferred as more correct, and affects search path of the binary itself, but not of any of the dependent libraries.
The DT_RPATH has global effect, similar to adding the directory to LD_LIBRARY_PATH environment variable.
You can verify this with: readelf -d a.out | grep 'R.*PATH'.
If you do see the RPATH vs. RUNPATH difference, and in fact are using Gold, you can force the "old" behavior with -Wl,--disable-new-dtags (GNU ld also had --disable-new-dtags added to it recently, so it should work for either linker).
Is there a way to check the configuration of armadillo from a c++ program? I just want to make sure armadillo has been compiled with 'atlas' or 'openblas'
I found arma::arma_config cfg; but I have no idea what cfg contains. I've done some testing and found blas and atlas but openblas does not seem to be an option. Is there anywhere I can find a complete list of what cfg contains?
That is common misunderstanding. Armadillo uses the LAPACK/BLAS interface and you can switch the libraries out at will.
edd#rob:/tmp$ g++ -o armadillo_example armadillo_example.cpp -larmadillo
edd#rob:/tmp$ ./armadillo_example
A*trans(B) =
-0.3111 -0.3320 -0.8700 -0.8698
0.1312 -0.7760 -0.2394 -0.6150
-0.2320 -1.2993 -0.6748 -1.3584
-0.1677 -1.9175 0.6289 -0.5619
edd#rob:/tmp$ ldd armadillo_example
linux-vdso.so.1 (0x00007fff92b5b000)
libarmadillo.so.9 => /usr/lib/libarmadillo.so.9 (0x00007fe598ea5000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe598cc4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe598b75000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe598b5a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe598970000)
libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007fe598910000)
liblapack.so.3 => /usr/lib/x86_64-linux-gnu/liblapack.so.3 (0x00007fe598271000)
libarpack.so.2 => /usr/lib/x86_64-linux-gnu/libarpack.so.2 (0x00007fe598229000)
libsuperlu.so.5 => /usr/lib/x86_64-linux-gnu/libsuperlu.so.5 (0x00007fe5981b9000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe598ef1000)
libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 (0x00007fe596025000)
libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007fe595d5d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe595d39000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fe595cef000)
edd#rob:/tmp$
The armadillo shared library has similar links:
edd#rob:/tmp$ ldd /usr/lib/libarmadillo.so.9
linux-vdso.so.1 (0x00007ffc98853000)
libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f6043563000)
liblapack.so.3 => /usr/lib/x86_64-linux-gnu/liblapack.so.3 (0x00007f6042ec6000)
libarpack.so.2 => /usr/lib/x86_64-linux-gnu/libarpack.so.2 (0x00007f6042e7e000)
libsuperlu.so.5 => /usr/lib/x86_64-linux-gnu/libsuperlu.so.5 (0x00007f6042e0e000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6042c2d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6042ade000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6042ac1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f60428d7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f60435ff000)
libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 (0x00007f6040743000)
libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007f604047b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6040459000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f604040d000)
edd#rob:/tmp$
On my Ubuntu system /usr/lib/x86_64-linux-gnu/libblas.so.3 is a softlink that gets updated when another BLAS/LAPACK package is installed allowing you to easil switch (which I use e.g. in this GitHub repo to show how to easily install MKL.
The structure of arma_config can be found in /usr/include/armadillo_bits/arma_config.hpp or wherever locate arma_config finds the file.
I've already read this, this and this.
I've installed OpenCV in a costum path /home/luca/ParallelOpenCV/install_icpc/lib, where there is libopencv_core.so:
luca#jarvis:~$ ldd /home/luca/ParallelOpenCV/install_icpc/lib/libopencv_core.so
linux-vdso.so.1 => (0x00007ffccb389000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f46af719000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f46af410000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f46af1f2000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f46aefea000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f46aedd0000)
libimf.so => /opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64/libimf.so (0x00007f46ae8e3000)
libsvml.so => /opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64/libsvml.so (0x00007f46ad9d8000)
libirng.so => /opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64/libirng.so (0x00007f46ad663000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f46ad2e0000)
libiomp5.so => /opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64/libiomp5.so (0x00007f46acf3d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f46acd27000)
libintlc.so.5 => /opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64/libintlc.so.5 (0x00007f46acabc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f46ac6f3000)
/lib64/ld-linux-x86-64.so.2 (0x000055f67574e000)
I added the path to LD_LIBRARY_PATH and I executed ldconfig, but:
luca#jarvis:~$ ldd libopencv_core.so
ldd: ./libopencv_core.so: No such file or directory
What am I missing?
From man ldd:-
NAME
ldd - print shared object dependencies
SYNOPSIS top
ldd [option]... file...
DESCRIPTION
ldd prints the shared objects (shared libraries) required by each
program or shared object specified on the command line. An example
of its use and output is the following:
$ ldd /bin/ls
linux-vdso.so.1 (0x00007ffcc3563000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f87e5459000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f87e5254000)
libc.so.6 => /lib64/libc.so.6 (0x00007f87e4e92000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f87e4c22000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f87e4a1e000)
/lib64/ld-linux-x86-64.so.2 (0x00005574bf12e000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f87e4817000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f87e45fa000)
The output of your command:
luca#jarvis:~$ ldd libopencv_core.so
ldd: ./libopencv_core.so: No such file or directory
says that the program or shared object supposedly specified on the
commandline does not exist in the implied directory = ./ = /home/luca.
We know it exists in /home/luca/ParallelOpenCV/install_icpc/lib.
If you run ldd file, where file, after shell expansion, is the pathname
of an existing file, then ldd will display the dynamic dependencies
of that file, as discovered by the dynamic linker with its usual reliance upon
the current ldconfig configuration and its usual regard to the operative
LD_LIBRARY_PATH environment setting. It will not search your system
for files that might be alternate candidates for a file that does not exist
and display the dynamic dependencies of those candidates.
I just built GCC 5.1 on Ubuntu 14.04, which has gcc 4.8 as default. When I try to build things with it, I find that ld will use the default libstdc++ instead of the newly build one.
Here is the output:
drizzlex#dx ~/test
$ g++ hello.cpp
drizzlex#dx ~/test
$ ldd a.out
linux-vdso.so.1 => (0x00007ffde0d25000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa181ad2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa1817cc000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa1815b5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa1811f0000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa181dfd000)
And if I use $ export LD_LIBRARY_PATH=/usr/local/lib64/, it will find the right one.
drizzlex#dx ~/test
$ ldd a.out
linux-vdso.so.1 => (0x00007fffeeaf5000)
libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00007f4583d92000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4583a67000)
libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00007f4583850000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f458348b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f458410e000)
I would like to know what should I do to make it correct? Since I know set LD_LIBRARY_PATH is not the best choice.
For building with g++ 5.1 use this:
$ g++5.1 hello.cpp -Wl,-rpath,/usr/local/lib64
And you will not need set LD_LIBRARY_PATH.
This is from https://en.wikipedia.org/wiki/Rpath
rpath is a term in programming which refers to a run-time search path
hard-coded in an executable file or library, used during dynamic
linking to find the libraries the executable or library requires.