I'm using a Linux machine to build Android applications and have run into this error while running this command.
apktool b GoogleCamera -o GC.apk
This is the error it out puts
W: /usr/bin/aapt: error while loading shared libraries: libc++.so: cannot open shared object file: No such file or directory
Exception in thread "main" brut.androlib.AndrolibException: brut.androlib.AndrolibException: brut.common.BrutException: could not exec (exit code = 127): [/usr/bin/aapt, p, --min-sdk-version, 26, --target-sdk-version, 27, --version-code, 41362666, --version-name, 5.1.018.177470874, --no-version-vectors, -F, /tmp/APKTOOL5938966552810672173.tmp, -0, arsc, -0, META-INF/services/com.google.protobuf.GeneratedExtensionRegistryLoader, -0, apk, -0, bin, -0, arsc, -I, /root/.local/share/apktool/framework/1.apk, -S, /root/Downloads/GoogleCamera/res, -M, /root/Downloads/GoogleCamera/AndroidManifest.xml]
When I check aapt like this
cd /usr/bin
ldd aapt
It returns
linux-gate.so.1 (0xb7f37000)
libc++.so => not found
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb7e0b000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7e06000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7de7000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb7dcc000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7cd1000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7cb3000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7adf000)
/lib/ld-linux.so.2 (0xb7f39000)
Related
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'm running into a symbol lookup error whenever I run a specific version/configuration of the simulator Gem5, using commit c5ca3ef6b9ff967722b07bc160fa9068e0d9e39c.
The building is done by a SConscript (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)), and after running the program
./build/X86/gem5.opt ./configs/example/se.py -<test program> <configs>
the following error is generated:
symbol lookup error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: undefined symbol: _ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv, version GLIBCXX_3.4
Checking nm's output, I notice the symbol is there
nm -D /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep _ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv
000000000008e4d0 T _ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv
Then, as suggested by another answer, I check ldd:
ldd build/X86/gem5.opt
linux-vdso.so.1 => (0x00007fff8b5d9000)
libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007fe4b4534000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe4b4317000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe4b40fd000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe4b3ef5000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe4b3b73000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe4b386a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe4b3654000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe4b328a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe4b3086000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fe4b2e83000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe4b4ac2000)
And as can be seen, libstdc++ is being chosen correctly. Would anyone have a suggestion to fix this linking problem?
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 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'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$