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.
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.
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 am trying to integrate the 3G video gateway with Asterisk(1.4.0).
When i load the module "app_transcoder.so" (which does the actual video transcoding), then
asterisk hangs and with "asterisk -vvvvvc" i got
asterisk: symbol lookup error: /usr/lib/asterisk/modules/app_transcoder.so: undefined symbol: avcodec_init
Showing the dependencies of app_transcoder.so by "ldd /usr/lib/asterisk/modules/app_transcoder.so" gives:
linux-vdso.so.1 => (0x00007fff851ff000)
libavcodec.so.54 => /usr/local/lib/libavcodec.so.54 (0x00007f8604ec3000)
libswscale.so.2 => /usr/local/lib/libswscale.so.2 (0x00007f8604c6e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f86048d9000)
libavutil.so.52 => /usr/local/lib/libavutil.so.52 (0x00007f86046a7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f860448a000)
libx264.so.142 => /usr/local/lib/libx264.so.142 (0x00007f86040d1000)
libgsm.so.1 => /usr/lib/libgsm.so.1 (0x00007f8603ec6000)
libm.so.6 => /lib64/libm.so.6 (0x00007f8603c42000)
libz.so.1 => /lib64/libz.so.1 (0x00007f8603a2b000)
/lib64/ld-linux-x86-64.so.2 (0x0000003b14200000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f8603827000)
"avcodec_init" comes from libavcodec.so file but it has no symbols as from the commands:
nm -a /usr/local/lib/libavcodec.so.54
gives:
nm: /usr/local/lib/libavcodec.so.54: no symbols
i am following the instructions from Medooze
CentOS-6.4
ffmpeg-1.2.6
asterisk-1.4.0
x264- 0.142x
ptlib-2.6.7
mpeg4ip-1.6.1
Any advice is appreciated.
add /usr/local/lib to your library path /etc/ld.so.conf
after that, execute "ldconfig"
recompile asterisk.
Found this ffmpeg mailing list: avcodec_init() isn't used nowadays. Instead avcodec_register_all() is used. It seems you may need to downgrade ffmpeg.
I know there is a lot about this on the internet and I have tried most of it without luck. Most solutions says that en environment variable is missing aka (LD_LIBRARY_PATH) which i pointed it to the file in user and root but it still does not pick it up. I am not sure what exactly is looking for the library or how to fix this??
Any ideas?
EDIT
ldd output:
linux-vdso.so.1 => (0x00007fffb97ff000)
libmysqlcppconn.so.7 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f002fdb3000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f002fb9c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f002f7dd000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f002f5c0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f002f2c3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f00300c7000)
Here's how you correctly set the library path...
If your library is at /usr/local/lib/libmylib.so.4 and your program is ./myprog:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib ./myprog
I'm trying to Hoard allocator to work, but it seems it doesn't. I have a benchmark application that does a lot of dynamic memory management. The execution time for Hoard and glibc memory manager is the same. It makes me wonder if I'm doing the right thing.
What I do is...
export LD_PRELOAD="/path/libhoard.so"
g++ main.cpp -O3 -o bm -lpthread -lrt
Shouldn't I have to link to Hoard allocator? Does it matter what path (in LD_PRELOAD) is, or can I have whatever path?
I'm running Ubuntu 8.04, and g++ 4.2.4
Cheers
No one knows any Linux command (such as grep) to find out if Hoard is loaded properly, and is the actual allocator used?
Author of Hoard here.
(a) Any path for LD_PRELOAD is fine (as long as it is correct).
(b) To see whether your code is using Hoard or not, use the ldd command. If everything went according to plan, then you will see the Hoard library (notice the second line after the second invocation of ldd).
Best,
-- Emery Berger
bash-3.2$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fffe6dfd000)
librt.so.1 => /lib64/librt.so.1 (0x0000003159600000)
libacl.so.1 => /lib64/libacl.so.1 (0x000000315e200000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x000000315d200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003154e00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003155a00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003154a00000)
libattr.so.1 => /lib64/libattr.so.1 (0x0000003162000000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003155600000)
libsepol.so.1 => /lib64/libsepol.so.1 (0x000000315ce00000)
bash-3.2$ export LD_PRELOAD=$PWD/libhoard.so
bash-3.2$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fff24bfd000)
/nfs/cm/users1/emery/scratch/projects/hoard/trunk/src/libhoard.so (0x00002b4885f42000)
librt.so.1 => /lib64/librt.so.1 (0x0000003159600000)
libacl.so.1 => /lib64/libacl.so.1 (0x000000315e200000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x000000315d200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003154e00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003155600000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003155a00000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000315b200000)
libm.so.6 => /lib64/libm.so.6 (0x0000003155200000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000315aa00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003154a00000)
libattr.so.1 => /lib64/libattr.so.1 (0x0000003162000000)
libsepol.so.1 => /lib64/libsepol.so.1 (0x000000315ce00000)
bash-3.2$