gcc arm ausführbare Datei "keine solche Datei orr Verzeichnis", falsche dynamische lib

Question

Ich versuche, eine brauchbare Setup für gcc-linaro-arm-linux-gnueabihf-4.8-2013.11 auf Windows zu machen. Etwas passiert bei Dynamic Link:

$(CC)-gcc -o test main.c -Wall -lc 

Das Programm kompiliert gut, aber wenn im Einsatz zeigt ARM: „Keine solche Datei oder das Verzeichnis“

Suche das Problem scheint, dass die statische Aufladung funktioniert, aber ausführbar ist riesig:

$(CC)-gcc -static -o test main.c -Wall -lc 

Jetzt habe ich eine installierte VisualGDB Werkzeugkette, die (in IDE) mit einem eigenen Werkzeugkette eine ähnliche ausführbare Datei (klein, dynamisch), die ich denke, das ist nichts mit meiner ARM dist falsch funktioniert so baut Ribution.

Fehle ich etwas oder falsch enthalten von gcc-linaro-arm-linux-gnueabihf-4.8-2013.11?

Vielen Dank im Voraus,

Eine weitere Untersuchung:

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 -readelf laufen (für nicht arbeiten):

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 

und Arbeiten:

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 +++ 

Answer 1

Ich löste mich selbst, danke für die Unterstützung sowieso.

Der Cross-Compiler von Linaro verlinkt mit einem neuen lib-Namen (einige Namen ändern sich in Debian) wie /lib/ld-linux-armhf.so.3, aber die BBB (default) -Verteilung verwendet einen alten Namen/lib /ld-linux.so.3. Beide Namen sollten auf BBB verweisen (Symlinks) auf real verwendete Bibliothek, die ist ld-2.16.so

Also erstellen Sie einen anderen Symlink und das ist es.

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 

Beste Grüße und Frohe Weihnachten an alle,

Answer 2

Ich kann Folgendes denken, wie ich einige ähnliche Probleme hatte zuvor.

Die Armverteilung hat die erforderlichen Bibliotheken in einem Ordner wie/usr/lib oder/lib in ihrer Distribution oder einem anderen Ordner und Ihre Kompilierungsumgebung hat diese an einem anderen Ort. Wenn dies der Fall ist, dann entweder

• den Bibliothekspfad Einstellung LD_LIBRARY_PATH Umgebungsvariable (oder .bashrc)
• oder die Schaffung der gleichen Ordnerstruktur kann helfen, wie Sie in Ihrem System haben auch

helfen kann

Ich kann sehen, dass Ihre Kreuzkompilierung keine hardwarespezifischen Bibliotheken berücksichtigt, sondern nur die Systembibliotheken der neuen Hardware, von denen sie abhängig sein wird.

Natürlich nehme ich an, dass Sie ein chmod gemacht haben, um Ihr Programm zu einer ausführbaren Datei in Ihrer Arm Hardware oder Emulator zu machen.

Answer 3

Möglicherweise ist es eine fehlende gemeinsam genutzte Bibliothek auf dem Bereitstellungscomputer.

Versuchen Sie, $(CC)-readelf -d your-binary | grep NEEDED auszuführen. Dadurch werden die Namen der erforderlichen gemeinsam genutzten Bibliotheken angezeigt. Überprüfen Sie, ob sie auf dem Zielcomputer vorhanden sind

Versuchen Sie, ldd you-binary auf dem Zielcomputer auszuführen. Es sollte berichten, welche dynamischen Bibliotheken benötigt und ob sie gefunden wurden.

PS. Führen Sie das Programm auf dem Ziel mit strace your-binary aus. Suchen Sie nach open oder access Aufrufe, die Fehler ENOENT zurückgeben.