gcc arm executable "no such file orr directory", wrong dynamic lib
I am trying to make a usable setup for gcc-linaro-arm-linux-gnueabihf-4.8-2013.11 on windows. Something happens at dynamic link:
$(CC)-gcc -o test main.c -Wall -lc
The program compiles fine, but when deployed to ARM shows: "No such file or directory"
Searching the issue, seems that static build works but executable is huge:
$(CC)-gcc -static -o test main.c -Wall -lc
Now I have a VisualGDB toolchain installed that builds (in IDE) with it's own toolchain a similar executable (small, dynamic) that works so I guess this is nothing wrong with my ARM distribution.
Am I missing something or wrong include from gcc-linaro-arm-linux-gnueabihf-4.8-2013.11 ?
Thanks very much in advance,
One more investigation:
file test
working (compiled with VisualGDB toolchain)
test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
mot working (compiled with gcc-linaro-arm-linux-gnueabihf-4.8-2013.11)
test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.1.1, BuildID[sha1]=0x13accf06af902cd8b96d85b8a412e1d7822a302b, not stripped
my ARM
3.8.13
I run -readelf (for non working):
Dynamic section at offset 0x474 contains 24 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000c (INIT) 0x82a0
0x0000000d (FINI) 0x8434
0x00000019 (INIT_ARRAY) 0x10468
0x0000001b (INIT_ARRAYSZ) 4 (bytes)
0x0000001a (FINI_ARRAY) 0x1046c
0x0000001c (FINI_ARRAYSZ) 4 (bytes)
0x00000004 (HASH) 0x8194
0x00000005 (STRTAB) 0x820c
0x00000006 (SYMTAB) 0x81bc
0x0000000a (STRSZ) 65 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x1055c
0x00000002 (PLTRELSZ) 32 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x8280
0x00000011 (REL) 0x8278
0x00000012 (RELSZ) 8 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x8258
0x6fffffff (VERNEEDNUM) 1
0x6ffffff0 (VERSYM) 0x824e
0x00000000 (NULL) 0x0
and working:
Dynamic section at offset 0x4d0 contains 24 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000c (INIT) 0x8274
0x0000000d (FINI) 0x8490
0x00000019 (INIT_ARRAY) 0x104c4
0x0000001b (INIT_ARRAYSZ) 4 (bytes)
0x0000001a (FINI_ARRAY) 0x104c8
0x0000001c (FINI_ARRAYSZ) 4 (bytes)
0x00000004 (HASH) 0x8168
0x00000005 (STRTAB) 0x81e0
0x00000006 (SYMTAB) 0x8190
0x0000000a (STRSZ) 65 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x105b8
0x00000002 (PLTRELSZ) 32 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x8254
0x00000011 (REL) 0x824c
0x00000012 (RELSZ) 8 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x822c
0x6fffffff (VERNEEDNUM) 1
0x6ffffff0 (VERSYM) 0x8222
0x00000000 (NULL) 0x0
strace log:
execve("/usr/bin/test", ["test"], [/* 15 vars */]) = 0
brk(0) = 0x17000
uname({sys="Linux", node="beaglebone", ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f8a000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=54751, ...}) = 0
mmap2(NULL, 54751, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f57000
close(3) = 0
open("/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0@\321\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1505830, ...}) = 0
mmap2(NULL, 152384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f31000
mprotect(0xb6f4f000, 28672, PROT_NONE) = 0
mmap2(0xb6f56000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d) = 0 xb6f56000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\210\177\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1205468, ...}) = 0
mmap2(NULL, 1246600, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e00000
mprotect(0xb6f24000, 28672, PROT_NONE) = 0
mmap2(0xb6f2b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x123) = 0xb6f2b000
mmap2(0xb6f2e000, 9608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb 6f2e000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f89000
set_tls(0xb6f896d0, 0xb6f89da8, 0xb6f8c058, 0xb6f896d0, 0xb6f8c058) = 0
mprotect(0xb6f2b000, 8192, PROT_READ) = 0
mprotect(0xb6f8b000, 4096, PROT_READ) = 0
munmap(0xb6f57000, 54751) = 0
brk(0) = 0x17000
brk(0x38000) = 0x38000
close(1) = 0
close(2) = 0
exit_group(1) = ?
+++ exited with 1 +++
4 Answers
I solved by myself, thanks for support anyhow.
The cross-compiler from Linaro links with a new lib name (some name changes in Debian) such as /lib/ld-linux-armhf.so.3 but the BBB (default) distribution use a old name /lib/ld-linux.so.3. Both names should point (symlinks) on BBB to real used library which is ld-2.16.so
So create another symlink and that's it.
ln -s /lib/ld-2.16.so /lib/ld-linux-armhf.so.3
-rwxr-xr-x 1 root root 130304 Mar 20 2013 /lib/ld-2.16.so
lrwxrwxrwx 1 root root 15 Dec 24 23:14 /lib/ld-linux-armhf.so.3 -> /lib/ld-2.16.so <-- new one
lrwxrwxrwx 1 root root 10 Jun 19 2013 /lib/ld-linux.so.3 -> ld-2.16.so
Best regards and Merry Christmas to all,
user1797147It might well be a missing shared library on the deployment machine.
Try running $(CC)-readelf -d your-binary | grep NEEDED. This will display the names of the required shared libraries. Verify that they are present on the target machine
Try running ldd you-binary on the target machine. It should report what are the required
dynamic libraries and if they have been found.
PS. Run the program on the target with strace your-binary. Look for open or access calls, which return error ENOENT.
chillI can think of the following as I had some similar issues before.
The arm distribution has the required libraries in a folder like /usr/lib or /lib in its distribution or some other folder and your compilation environment has these at a different location. If this is the case then either
- setting the library path using ld_library_path environment variable (or .bashrc) may help
- or creating the same folder structure as you have in your system may also help
I can see that your cross compilation does not take into account of any hardware specific libraries but it is just the new hardware's system libraries it is going to be dependent.
Ofcourse I am assuming that you have done a chmod to make your program an executable in your arm hardware or emulator.
MuthuThe compiler uses the ld-linux-armhf.so.3 loader instead of ld-linux.so.3 if you pass the option mfloat-abi=hard to the linker by adding it to the LDFLAGS. No need for a symlink. At least it solved the issue for my Yocto Poky toolchain. See https://github.com/golang/go/issues/12443
ThalionâthUser contributions licensed under CC BY-SA 3.0