While using the TBB dynamic library the following error occurred and how to use the tbb in Linux and how to solve the following error?
error : libirml.so.1 file not recognized : file format not recongnized
Please start by checking that the file libirml.so. is really a shared library using the ldd command:
$> ldd libirml.so.1
If the file is broken you will have a message like:
not a dynamic executable
Otherwise (case of a truly shared lib) you will have some info like these:
libc.so.6 => /lib/libc.so.6 (0x00002)
/lib/ld-linux-64.so.2 (0x00005)
Related
I am trying to cross compile a small rust application for the RPI. I am cross compiling because compiling directly on the PI takes way too long and it hits 75C.
I followed various instructions, but what I ended up doing is this:
Install "armv7-unknown-linux-gnueabihf" target with rustup
Download rpi tools from here: https://github.com/raspberrypi/tools
Add the "tools/arm-bcm2708/arm-linux-gnueabihf/bin/" folder to PATH
Add ".cargo/config" file with:
[target.armv7-unknown-linux-gnueabihf]
linker = "arm-linux-gnueabihf-gcc"
run "cargo build --target armv7-unknown-linux-gnueabihf --release"
scp the file to the RPI
chmod +x the_file
do "./the_file"
I get bash: ./the_file: No such file or directory
Yes, I am indeed in the right directory.
So this is the output from "file":
ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically
linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32,
with debug_info, not stripped
I'm not experienced enough with this sort of stuff to determine if the binary that I produced is suitable to be run on an RPI3 B.
Did I produce the correct "type" of binary?
P.S. I am running DietPi distro on the PI. It is based on debian if that's of any relevance.
So I solved this by cheating. I found https://github.com/rust-embedded/cross which took about 30 seconds to get going and now I can cross compile to pretty much anything. I highly recommend it!
The error message "No such file or directory" is not about the your executable but about the dynamic libraries linked to it which are missing from the target system.
To find out which libraries your executable needs you have to run the following command.
ldd /usr/bin/lsmem
This will output something like this
linux-vdso.so.1 (0x00007fffc87f1000)
libsmartcols.so.1 => /lib/x86_64-linux-gnu/libsmartcols.so.1 (0x00007fe82fe71000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe82fc7f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe82fedd000)
Now you have to check that all this libraries are available on your system. rust-cross probably uses the correct linker for your target so that is probably the reason this works with it. To modify the linker see https://stackoverflow.com/a/57817848/5809980
I'am trying build boost 1.69 on Solaris 11.3 with gcc 4.8.2.
Then build is complete i'am see (with ldd libname.so) that linker using relative path in dynamic section tag NEEDED
bin.v2/libs/atomic/build/gcc-4.8.2/release/threading-multi/visibility-hidden/libboost_atomic.so.1.69.0
It is not good. I want to linker use only libname without any path (absolute or relative).
How i can set short name link?
So: outut ldd from solaris and ldd from RHEL 6
Solaris
ldd libboost_thread.so.1.69.0
**bin.v2/libs/system/build/gcc-4.8.2/release/threading-multi/visibility-hidden/libboost_system.so.1.69.0** => bin.v2/libs/system/build/gcc-4.8.2/release/threading-multi/visibility-hidden/libboost_system.so.1.69.0
.........
linux
ldd libboost_thread.so.1.69.0
linux-gate.so.1 => (0x00ba6000)
**libboost_system.so.1.69.0** => /usr/lib/libboost_system.so.1.69.0 (0x00a53000)
........
Why on Solaris boost building with using crasy path in dependency name, but on Linux - it normal - only libname without any path. How i can say to b2 or other tool to use only short dependency name?
The Solaris linker is simply recording what it was told - it appears the command to link the software passed bin.v2/libs/system/build/gcc-4.8.2/release/threading-multi/visibility-hidden/libboost_system.so.1.69.0 to the linker, instead of the normal -Lbin.v2/libs/system/build/gcc-4.8.2/release/threading-multi/visibility-hidden/ -lboost_system. You'll have to look into the build scripts/Makefiles to determine why it's doing that.
I am using nvcodec sdk (https://developer.nvidia.com/nvidia-video-codec-sdk) and use its linux static library in my project.
I added the compile option in gcc with
gcc myprogram.c NvCodec/Lib/linux/stubs/x86_64/libnvcuvid.so
However, when running the program,
./bin/a.out: symbol lookup error: ./bin/a.out: undefined symbol: cuvidGetDecodeStatus
I found that the symbol cuvidGetDecodeStatus is actually in NvCodec/Lib/linux/stubs/x86_64/libnvcuvid.so.
And by
nm a.out
the symbol is included in the program.
so I tried
ldd a.out
I found it's linked to nvidia driver with same name.
libnvcuvid.so.1 => /usr/lib/nvidia-384/libnvcuvid.so.1
I can't modify the LD_LIBRARY_PATH to modify the search order since NvCodec is a static library.
I have no idea why it's linked to the nvidia driver library even I don't add link option (like -lnvcuvid)
And idea?
thank you
as #Robert Crovella said,
this is an issue for an outdated driver. the library in the cuda codec sdk is actually a stub, which points to the cuda driver shared library.
And there is no symbol like cuvidGetDecodeStatus in the nvidia-384 driver library.
after update nvidia-384 to nvidia-396, the problem solved.
I receive this error when linking -lboost_thread into my executable on google Native Client (pepper_19):
nacl_sdk/pepper_19/toolchain/mac_x86_glibc/x86_64-nacl/usr/lib/libboost_thread.a: could not read symbols: Archive has no index; run ranlib to add one
I compiled boost according to the instructions at naclports here: http://code.google.com/p/naclports/wiki/InstallingSDL (except using the boost library directory instead of SDL... I also used this same process to correctly compile NaCl zlib library)
cd naclports/src/libraries/boost_1_47_0
export NACL_PACKAGES_BITSIZE=32; ./nacl-boost_1_47_0.sh
export NACL_PACKAGES_BITSIZE=64; ./nacl-boost_1_47_0.sh
this generates the libboost_thread.a file and puts it them in the /usr/lib directories of my NACL installation. I thought maybe somehow I mistakenly built a wrong type of library for linking with NaCl. Is there a way to check this and/or fix it?
I tried:
cd naclports/src/out/repository-x86_64/boost_1_47_0/bin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi
nm libboost_thread.a
and this yielded:
libboost_thread.a(thread.o):
0000000000052d08 s EH_frame0
000000000004f50c s GCC_except_table100
000000000004f534 s GCC_except_table101
000000000004f574 s GCC_except_table102
000000000004f5c0 s GCC_except_table103
000000000004f600 s GCC_except_table104
000000000004f64c s GCC_except_table105
000000000004f68c s GCC_except_table106
000000000004f6d8 s GCC_except_table107
.
.
.
.
etc, etc..
However then I ran:
nacl_sdk/pepper_19/toolchain/mac_x86_glibc/bin/x86_64-nacl-nm libboost_thread.a
and got:
__.SYMDEF SORTED: File format not recognized
nacl_sdk/pepper_19/toolchain/mac_x86_glibc/bin/x86_64-nacl-nm: thread.o: File format not recognized
nacl_sdk/pepper_19/toolchain/mac_x86_glibc/bin/x86_64-nacl-nm: once.o: File format not recognized
And finally. I ran:
file pthread/thread.o
pthread/thread.o: Mach-O 64-bit object x86_64
however the same command on a zlib object file results in:
ELF 64-bit LSB relocatable, x86-64, version 1, not stripped
I would appreciate advice on building a correctly cross-compiled NaCl libboost_thread.a
Thank you.
Some libraries in NaCl ports can only be built on linux. So you have to either find why boost decides to use system ar instead of x86_64-nacl-ar or install VM with linux where they are the same.
There is a laptop on which I have no root privilege.
onto the machine I have a library installed using configure --prefix=$HOME/.usr .
after that, I got these files in ~/.usr/lib :
libXX.so.16.0.0
libXX.so.16
libXX.so
libXX.la
libXX.a
when I compile a program that invokes one of function provided by the library with this command :
gcc XXX.c -o xxx.out -L$HOME/.usr/lib -lXX
xxx.out was generated without warning, but when I run it error like this was thrown:
./xxx.out: error while loading shared libraries: libXX.so.16: cannot open shared object file: No such file or directory , though libXX.so.16 resides there.
my clue-less assumption is that ~/.usr/lib wasn't searched when xxx.out is invoked.
but what can I do to specify path of .so , in order that xxx.out can look there for .so file?
An addition is when I feed -static to gcc, another error happens like this:
undefined reference to `function_proviced_by_the_very_librar'
It seems .so does not matter even though -L and -l are given to gcc.
what should I do to build a usable exe with that library?
For other people who has the same question as I did
I found a useful article at tldp about this.
It introduces static/shared/dynamic loaded library, as well as some example code to use them.
There are two ways to achieve that:
Use -rpath linker option:
gcc XXX.c -o xxx.out -L$HOME/.usr/lib -lXX -Wl,-rpath=/home/user/.usr/lib
Use LD_LIBRARY_PATH environment variable - put this line in your ~/.bashrc file:
export LD_LIBRARY_PATH=/home/user/.usr/lib
This will work even for a pre-generated binaries, so you can for example download some packages from the debian.org, unpack the binaries and shared libraries into your home directory, and launch them without recompiling.
For a quick test, you can also do (in bash at least):
LD_LIBRARY_PATH=/home/user/.usr/lib ./xxx.out
which has the advantage of not changing your library path for everything else.
Should it be LIBRARY_PATH instead of LD_LIBRARY_PATH.
gcc checks for LIBRARY_PATH which can be seen with -v option