C++ executable fail to look up LD_LIBRARY_PATH - c++

I am building a simple C++ benchmark using a custom compilation tool (which has in-built clang plugin) and it simply is another regular C++ compiler. However whenever I try to run the compiled (and linked) binary, it never looks up for LD_LIBRARY_PATH to find the correct libstdc++ version. It always look for the standard /usr/lib64 and the libstdc++ version there is too old for my executable. I want to point my binary to look up in LD_LIBRARY_PATH when it runs. (I don't have root access.)
Below is the output when running it:
[xx#login-01 src]$ ./executable.x
./executable.x: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./executable.x)
Below is output from gcc --version command. This GCC version is sufficient but my executable doesn't look for its lib path, which is in LD_LIBRARY_PATH.
gcc (GCC) 9.2.0
Copyright (C) 2019 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.
echo $LD_LIBRARY_PATH output is below. Notice it has correct GCC lib path.
/cm/local/apps/gcc/9.2.0/lib:/cm/local/apps/gcc/9.2.0/lib64:/home/ri-wshilpage/tools/LLVM/llvm-project/build/lib:/home/ri-wshilpage/tools/LLVM/llvm-project/build/lib/libomp.so:/opt/gcc/8.1.0/snos/lib64:/opt/cray/pe/papi/6.0.0.7/lib64:/cm/shared/apps/pbspro/19.2.8.20200925072630/lib/
Below I have checked the output from readelf -d ./executable.x and its RPATH shows only /usr/lib64 and the lib path of the custom compiler.
Dynamic section at offset 0x92d58 contains 34 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libhipSYCL-rt.so]
0x0000000000000001 (NEEDED) Shared library: [libboost_context.so.1.66.0]
0x0000000000000001 (NEEDED) Shared library: [libboost_fiber.so.1.66.0]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libomp.so]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000f (RPATH) Library rpath: [/lustre/home/xx/sycl-compilers/hipSYCL/build/install/bin/../lib/:/usr/lib64]
0x000000000000000c (INIT) 0x407000
0x000000000000000d (FINI) 0x477d98
0x0000000000000019 (INIT_ARRAY) 0x493980
0x000000000000001b (INIT_ARRAYSZ) 160 (bytes)
0x000000000000001a (FINI_ARRAY) 0x493a20
0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
0x0000000000000004 (HASH) 0x400320
0x000000006ffffef5 (GNU_HASH) 0x400b70
0x0000000000000005 (STRTAB) 0x402798
0x0000000000000006 (SYMTAB) 0x400e90
0x000000000000000a (STRSZ) 12941 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000015 (DEBUG) 0x0
0x0000000000000003 (PLTGOT) 0x494000
0x0000000000000002 (PLTRELSZ) 4056 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x405fe8
0x0000000000000007 (RELA) 0x405df0
0x0000000000000008 (RELASZ) 504 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffffe (VERNEED) 0x405c40
0x000000006fffffff (VERNEEDNUM) 6
0x000000006ffffff0 (VERSYM) 0x405a26
0x0000000000000000 (NULL) 0x0
And finally here's the Makefile.
#-----------------------------------------------------------------------
# This file compiles for OpenMP and MPI hybrid operations using the GNU
# compile chain.
MINIFE_TYPES = \
-DMINIFE_SCALAR=double \
-DMINIFE_LOCAL_ORDINAL=int \
-DMINIFE_GLOBAL_ORDINAL=int \
-DMINIFE_RESTRICT=__restrict__
MINIFE_MATRIX_TYPE = -DMINIFE_CSR_MATRIX
#-----------------------------------------------------------------------
CXX = syclcc
CC = syclcc
OPTIMIZE = yes
CPPFLAGS = --gcc-toolchain=/lustre/projects/bristol/modules/gcc/9.2.0 --hipsycl-targets=omp -I. -I../utils -I../fem $(MINIFE_TYPES) -I../../include/ $(MINIFE_MATRIX_TYPE) \
-std=c++17 -I/home/xx/tools/LLVM/llvm-project/build/projects/openmp/runtime/src
ifeq ($(OPTIMIZE),yes)
CFLAGS += -O3
endif
CXXFLAGS = $(CFLAGS)
include make_targets
Also note that I have built LLVM from source (version 12.0.1) and used it to build my custom compiler. Everything works fine except for the executable not looking up at LD_LIBRARY_PATH for shared libraries.
Edit:
Check the output from ldd ./executable.x below.
./executable.x: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./executable.x)
linux-vdso.so.1 (0x0000155555551000)
libhipSYCL-rt.so => /lustre/home/xx/sycl-compilers/hipSYCL/build/install/bin/../lib/libhipSYCL-rt.so (0x00001555554ff000)
libboost_context.so.1.66.0 => /usr/lib64/libboost_context.so.1.66.0 (0x0000155555128000)
libboost_fiber.so.1.66.0 => /usr/lib64/libboost_fiber.so.1.66.0 (0x0000155554ec5000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000155554b30000)
libm.so.6 => /usr/lib64/libm.so.6 (0x00001555547ae000)
libomp.so => /home/xx/tools/LLVM/llvm-project/build/lib/libomp.so (0x000015555540d000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x0000155554596000)
libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x0000155554376000)
libc.so.6 => /usr/lib64/libc.so.6 (0x0000155553fb4000)
libdl.so.2 => /usr/lib64/libdl.so.2 (0x0000155553db0000)
/lib64/ld-linux-x86-64.so.2 (0x000015555532b000)
librt.so.1 => /usr/lib64/librt.so.1 (0x0000155553ba7000)
libboost_filesystem.so.1.66.0 => /usr/lib64/libboost_filesystem.so.1.66.0 (0x000015555398c000)
libboost_system.so.1.66.0 => /usr/lib64/libboost_system.so.1.66.0 (0x0000155553787000)

Related

Integrating shared object in an application, ldd and readelf show different outputs

I am trying to integrate OpenCV into an application and facing some issues below.
error while loading shared libraries: libopencv_imgproc.so.4.1: cannot open shared object file: No such file or directory
However, when I check the output of ldd and readelf, below are the differences.
$readelf -d <app name>
0x0000000000000001 (NEEDED) Shared library: [libopencv_imgcodecs.so.4.1]
0x0000000000000001 (NEEDED) Shared library: [libopencv_core.so.4.1]
$ldd <app name>
libopencv_imgcodecs.so.4.1 => <path to opencv>/opencv/lib/libopencv_imgcodecs.so.4.1 (0x00007f04555b2000)
libopencv_imgproc.so.4.1 => <path to opencv>/opencv/lib/libopencv_imgproc.so.4.1 (0x00007f0453e8f000)
libopencv_core.so.4.1 => <path to opencv>/opencv/lib/libopencv_core.so.4.1 (0x00007f0452774000)
As shown above, libopencv_imgproc is missing from readelf output. Can someone point out what causes such behavior?

Why dynamic linked binary shows hard coded SO name?

Sorry it might be a stupid question.
I didn't link libaudit directly, but why its name shows in my binary?
Strings shows:
strings dataserver|grep libaudit
libaudit.so.0
readelf shows:
readelf -a dataserver|grep "Shared lib"
0x0000000000000001 (NEEDED) Shared library: [libsapcrypto.so]
0x0000000000000001 (NEEDED) Shared library: [libaio.so.1]
0x0000000000000001 (NEEDED) Shared library: [libnsl.so.1]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libpam.so.0]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [libaudit.so.0]
What does it mean and is there anyway I can check why it is added into my binary?
Thanks
Update
Thanks. I'm reading the links below and adding some more findings.
I find that libpam was linked and it requires libaudit.so.0
Check libpam.so.0
ldd /lib64/libpam.so.0
linux-vdso.so.1 => (0x00007ffff7fdf000)
libaudit.so.0 => /lib64/libaudit.so.0 (0x00007ffff7b80000) <-- libaudit
libdl.so.2 => /lib64/libdl.so.2 (0x00007ffff797c000)
libc.so.6 => /lib64/libc.so.6 (0x00007ffff7616000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fe0000)
However, I have 2 binaries, both linked libpam.so. For binary1, it list libaudit.so.0 as NEEDED, but for binary2, it doesn't.
binary1 (with libpam but not depends on libaudit.so.0):
readelf -d binary1|grep "Shared lib"
0x0000000000000001 (NEEDED) Shared library: [libsybcsi_core210.so]
0x0000000000000001 (NEEDED) Shared library: [libsybcsi_profiler210.so]
0x0000000000000001 (NEEDED) Shared library: [libsybcsi_propertiesconfig210.so]
0x0000000000000001 (NEEDED) Shared library: [libsybcsi_openssl210.so]
0x0000000000000001 (NEEDED) Shared library: [libaio.so.1]
0x0000000000000001 (NEEDED) Shared library: [libnsl.so.1]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libpam.so.0] <--- libpam
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
binary2 (with libpam but and depends on libaudit.so.0):
readelf -d binary2|grep "Shared lib"
0x0000000000000001 (NEEDED) Shared library: [libsapcrypto.so]
0x0000000000000001 (NEEDED) Shared library: [libaio.so.1]
0x0000000000000001 (NEEDED) Shared library: [libnsl.so.1]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libpam.so.0] <--- libpam
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [libaudit.so.0] <--- libaudit
It confused me a lot about the key word "NEEDED", when will a lib is "NEEDED" if it is not directly used?
What does it mean
It means your binary depends on it.
and is there anyway I can check why it is added into my binary?
Most likely the linker you used found that some other library on the link line depends on libaudit, and automagically added it in.
GNU-ld does this, and Gold doesn't (producing a steady stream of programs that have incorrect Makefiles and fail to link with Gold).
If you link with -v flag, you should see the actual link command, although it may be hidden by collect2 or some such wrapper.
Running the link under strace -fvs 1024 -e execve will show the actual link command for sure.
All right, I find the cause.
It's due to some reference of "_edata" and "_end" in my code.
In libpam.so, it is not found but libaudit.so which is needed for libpam.so, it was found and linker resolved it, then add libaudit as "NEEDED".
And _end is exposed as follows from linker scripts –
_end = .; PROVIDE (end = .);
This means, we should be using “end” and not “_end” unless we PROVIDE “_end” with our own linker scripts.
So, the fix is to change _end (and all such related symbols like _etext and _edata) to end (and etext, edata) so that they will be resolved correctly from standard libc, avoiding any dependency on other shared objects like libaudit.so.

FMOD Debian libfmod.so.8: cannot open shared object file: No such file or directory

I'm trying to install and validate fmod on my raspberry pi 1 model b with debian by running the provided example program play_stream. The compilation works fine however when I try to run the built executable it fails with the error
error while loading shared libraries: libfmod.so.8: cannot open shared object file: No such file or directory
I'm unsure of what i'm doing wrong. Any help or advice you can provide would be great
My set up:
~/fmodstudioapi10813linux/api/lowlevel/examples/make $ make --file play_stream.makefile CONFIG=Debug CPU=arm
~/fmodstudioapi10813linux/api/lowlevel/examples/make $ ./play_stream
./play_stream: error while loading shared libraries: libfmodL.so.8: cannot open shared object file: No such file or directory
~/fmodstudioapi10813linux/api/lowlevel/lib/arm $ ls /usr/local/lib/
libfmodL.so libfmodL.so.8 libfmodL.so.8.13 libfmod.so libfmod.so.8 libfmod.so.8.13
~ $ ls /usr/local/include/
fmod_codec.h fmod_common.h fmod_dsp_effects.h fmod_dsp.h fmod_errors.h fmod.h fmod.hpp fmod_output.h node
~ $ env | grep '^LD_LIBRARY_PATH'
LD_LIBRARY_PATH=:/usr/local/lib:/home/pi/fmodstudioapi10813linux/api/lowlevel/lib/arm
~/fmodstudioapi10813linux/api/lowlevel/examples/make $ ldd play_stream
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0xb6faf000)
libfmod.so.8 => not found
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6ec0000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6e45000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6e18000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6df0000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6caf000)
/lib/ld-linux-armhf.so.3 (0x7f56d000)
~/fmodstudioapi10813linux/api/lowlevel/examples/make $ echo $LD_LIBRARY_PATH
:/usr/local/lib:/home/pi/fmodstudioapi10813linux/api/lowlevel/lib/arm
**~/fmodstudioapi10813linux/api/lowlevel/examples/make $** readelf -d play_stream
Dynamic section at offset 0x420c contains 30 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libfmod.so.8]
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000f (RPATH) Library rpath: [$ORIGIN/../../../lowlevel/lib/arm/]
Run ldd play_stream and echo $LD_LIBRARY_PATH.

Valid ARM executable doesn't find libraries

I cross-compiled a small Hello World program for an ARM embedded device (an Asus RT-AC68U router running DD-WRT):
# arm-linux-gnueabi-g++ hello.cpp -mcpu=cortex-a9 -s -o hello
The file seems fine:
# file hello
hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=5099693c31154cdd7f04c16ced5b80b1e35e625b, stripped
It depends on a few libraries:
# readelf -d hello
Dynamic section at offset 0xf08 contains 26 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
(...)
When I try to execute the file on the target system, I get the following:
# ./hello
-sh: ./hello: not found
If I launch execution from ld-linux.so.3 without any other parameters, everything works:
# /opt/lib/ld-linux.so.3 ./hello
Hello, world.
When listing the libraries, the file seems to be searching for libraries in the /lib folder (they are not there, they are in /opt/lib):
# /opt/lib/ld-linux.so.3 --list ./hello
libstdc++.so.6 => /lib/libstdc++.so.6 (0x76dfb000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x76de0000)
libc.so.6 => /opt/lib/libc.so.6 (0x76cb2000)
libc.so => /lib/libc.so (0x76c35000)
/lib/ld-linux.so.3 => /opt/lib/ld-linux.so.3 (0x76f20000)
I'm guessing the error is due to the fact that the executable when launched on its own is not finding the required shared libraries. All the required libraries are present in the /opt/lib folder and this folder is included in LD_LIBRARY_PATH environment variable:
# echo $LD_LIBRARY_PATH
/lib:/usr/lib:/jffs/lib:/jffs/usr/lib:/jffs/usr/local/lib
:/mmc/lib:/mmc/usr/lib:/opt/lib:/opt/usr/lib
How do I get the executable to find the libraries in the right place?
Edit: I tried linking the libraries statically in the executable and the program runs fine on the target platform. However that is not a workable solution for what I want to do.
Your ld-linux.so.3 appears to be in a nonstandard location (/opt/lib), and it's possible that your gcc is specifying a different program interpreter. You can use readelf -l <program> to check what program interpreter your binary is expecting (under PT_INTERP, "Requesting program interpreter").
If the binary's program interpreter is wrong for your platform, you can specify it manually by passing -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 to gcc.

Cross-Compiled GNU ARM (BeagleBoneBlack) from Windows. Runtime Error on *.elf: "No such file or directory"

I'm in the (very) early stages of developing a UAV flight controller on a BeagleBone Black. I should mention that I'm quite the novice when it comes to the BBB, Linux and embedded systems.My academic focus has been on control theory - this is my first attempt at a practical implementation outside of Matlab Simulations. My current system is as follows:
Host-> Windows 8.1 x64 running Eclipse Luna (4.4.0)
Target -> BeagleBone Black rev. B running Ubuntu 13.10
Target Info
root#arm:~# uname -a
Linux arm 3.8.13-bone32 #1 SMP Fri Dec 13 20:05:25 UTC 2013 armv7l armv7l armv7l GNU/Linux
Target gcc version
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.1-10ubuntu9' --with-bugurl=file:///usr/shar
e/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --w
ith-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enabl
e-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --ena
ble-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr
/lib/jvm/java-1.5.0-gcj-4.8-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf --
with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/ja
va/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-
a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=arm-lin
ux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
I've installed the Sourcery Codebench Lite toolchain and am using the GNU Make file. I’ve set up the Eclipse environment as per the instructional video provided by Michael Jantz (link removed due to limit - if interested search "Cross-Compile and Remote Browsing for BeagleBone" on YouTube) with some minor tweaks to get it running on my system. These tweaks consisted primarily of removing the "--specs=rdimon.specs" and "-lrdimon" linking flags as I kept getting a "no such file or directory" when compiling. With these two flags removed the simple "Hello ARM World" program compiles without any issues.
After transferring the compiled ELF file to my BeagleBone, setting permissions and the executable flags via:
chmod ugo-x Test6.elf
and running it via:
./Test6.elf
I get the following message:
root#arm:/home/ubuntu/RDKTestProgs# ./Test6.elf
bash: ./Test6.elf: No such file or directory
I initially thought the mismatch between my 64-bit host system and the 32-bit GNU Make shouldn’t be an issue, but to eliminate my doubt I found a 64-bit GNU Make file (link removed due to limit) although I’m not sure of its integrity. In any case, both GNU Make files yield the same result when trying to execute the program on the BBB.
After looking through a several posts I discovered the “ readelf“, “strace” and “strings” tools, which yielded the following outputs.
Readelf:
root#arm:/home/ubuntu/RDKTestProgs# readelf -d Test6.elf
Dynamic section at offset 0x858 contains 27 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000c (INIT) 0x8550
0x0000000d (FINI) 0x87a0
0x00000019 (INIT_ARRAY) 0x10848
0x0000001b (INIT_ARRAYSZ) 8 (bytes)
0x0000001a (FINI_ARRAY) 0x10850
0x0000001c (FINI_ARRAYSZ) 4 (bytes)
0x00000004 (HASH) 0x8168
0x00000005 (STRTAB) 0x82bc
0x00000006 (SYMTAB) 0x81bc
0x0000000a (STRSZ) 444 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x10958
0x00000002 (PLTRELSZ) 72 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x8508
0x00000011 (REL) 0x84f8
0x00000012 (RELSZ) 16 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x8498
0x6fffffff (VERNEEDNUM) 3
0x6ffffff0 (VERSYM) 0x8478
0x00000000 (NULL) 0x0
root#arm:/home/ubuntu/RDKTestProgs# strings Test6.elf
/lib/ld-linux.so.3
libc.so.6
abort
__libc_start_main
__aeabi_atexit
libstdc++.so.6
__gmon_start__
_Jv_RegisterClasses
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
_ITM_deregisterTMCloneTable
_ITM_registerTMCloneTable
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
_ZNSt8ios_base4InitD1Ev
_ZNSolsEPFRSoS_E
_ZNSt8ios_base4InitC1Ev
_ZSt4cout
libm.so.6
libgcc_s.so.1
__aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr1
GLIBCXX_3.4
GCC_3.5
GLIBC_2.4
?8FAFJF
x`9`{h
Hello ARM World!
Strace:
root#arm:/home/ubuntu/RDKTestProgs# strace ./Test6
strace: Can't stat './Test6': No such file or directory
root#arm:/home/ubuntu/RDKTestProgs# strace ./Test6.elf
execve("./Test6.elf", ["./Test6.elf"], [/* 22 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
exit_group(1) = ?
+++ exited with 1 +++
Strings:
root#arm:/home/ubuntu/RDKTestProgs# strings Test6.elf
/lib/ld-linux.so.3
libc.so.6
abort
__libc_start_main
__aeabi_atexit
libstdc++.so.6
__gmon_start__
_Jv_RegisterClasses
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
_ITM_deregisterTMCloneTable
_ITM_registerTMCloneTable
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
_ZNSt8ios_base4InitD1Ev
_ZNSolsEPFRSoS_E
_ZNSt8ios_base4InitC1Ev
_ZSt4cout
libm.so.6
libgcc_s.so.1
__aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr1
GLIBCXX_3.4
GCC_3.5
GLIBC_2.4
?8FAFJF
x`9`{h
Hello ARM World!
I searched through my BeagelBoneBlack for the 4 shared library files indicated from the “readelf” function and found that they are in fact present. The issue is however, that some of these files are found in the usr/lib/arm-linux-gnueabihf/directory whereas others are found in the /lib/arm-linux-gnueabihf# directory. To fix this I created symbolic links to the files not found in the /usr/lib/arm-linux-gnueabihf/ directory. This still did not solve the problem. So I created symbolic links to files not found in the /lib/arm-linux-gnueabihf/ directory. Again, no luck.
Is there a way to check which directory is being used on execution? What else could possibly be missing from the Test6.elf file? I’m at a loss at the moment. Any advice or guidance would be greatly appreciated! Cheers!
P.S. I also managed to check for the GLIBCXX_3.4, GLIBC_2.4 and GCC_3.5 as shown below, but again, some of these pertain to files in /usr/lib/arm-linux-gnueabihf others are found in the /lib/arm-linux-gnueabihf. Thanks again!
root#arm:/lib/arm-linux-gnueabihf# strings libgcc_s.so.1 | grep GCC
GCC_3.0
GCC_3.3
GCC_3.3.1
GCC_3.3.4
GCC_3.4
GCC_3.4.2
GCC_4.0.0
GCC_4.2.0
GCC_4.3.0
GCC_4.7.0
GCC_3.5
root#arm:/usr/lib/arm-linux-gnueabihf# strings libstdc++.so.6.0.18 | grep GLIBC
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBC_2.4
GLIBC_2.17
GLIBCXX_DEBUG_MESSAGE_LENGTH
And finally, here's the "Hello ARM World" program
//============================================================================
// Name : main.cpp
// Author : RDK
// Version :
// Copyright : Your copyright notice
// Description : Hello World in C++
//============================================================================
#include <iostream>
using namespace std;
//
// Print a greeting message on standard output and exit.
//
// On embedded platforms this might require semi-hosting or similar.
//
// For example, for toolchains derived from GNU Tools for Embedded,
// to enable semi-hosting, the following was added to the linker:
//
// --specs=rdimon.specs -Wl,--start-group -lgcc -lc -lc -lm -lrdimon -Wl,--end-group
//
// Adjust it for other toolchains.
//
int
main()
{
cout << "Hello ARM World!" << endl;
return 0;
}
Right on! So I've got it working. Here are my steps, hopefully they're sound and wont cause me issues in the future.
From this post, I tried to find out where the Test6.elf expected to find the linux loader for dynamically linked libraries. This yielded:
root#arm:/home/ubuntu/RDKTestProgs# readelf -l ./Test6.elf | grep ld-linux
[Requesting program interpreter: /lib/ld-linux.so.3]
I checked my /lib folder and sure enough the ld-linux.so.3 file was missing. Instead I found it in the /lib/arm-linux-gnueabihf/ folder
So I created a symbolic link in the /lib folder via:
ln -s /lib/arm-linux-gnueabihf/ld-linux.so.3 /lib/ld-linux.so.3
And boom! It works. What I still find strange however is that the ldd ./Test6.elf still returns:
root#arm:/home/ubuntu/RDKTestProgs# ldd ./Test6.elf
not a dynamic executable
Is there a good reason for this, or is this somehow normal? - It doesn't seem right to me.
I also noticed that my current compiler settings (and hence toolchain) for Float ABI are set to soft, yet my BeagleBoneBlack is running arm-linux-gnueabihf - hard float. Will this cause me problems in the future? Should I be looking for a different toolchain?
Cheers!
I was having a similar situation with a library called 'ibstdc++.so.6'. I develop in Eclipse on Ubuntu 14.04, and deploy on beaglebone with Debian. I never had this issue before when I use to developed on Eclipse Ubuntu 12.04 and deploy on Amstrong.
The way I resolced the problem was reading the anwsers above and what I did I set my cross-compiler to arm-linux-gnueabihf-g++. Seems that the library that I was missing is just included in the hard floating version of the compiler and not in the soft floating. Change the cross compiler setting on Eclipse and resolved the problem.