C Fehler: No such file or directory, obwohl die Datei da ist.

chillking · 23. April 2018

Hi zusammen,

hab gerade angefangen mit einem Zynq zu arbeiten. Dazu muss man sagen, dass ich auch mit Linux noch komplett am Anfang stehe.
Habe ein kleines Programm für das Linux Real-Time geschrieben.
Wenn ich es per Eclipse unter Windows kompiliere und direkt auf das Board lade, funktioniert alles.
Wenn ich die Binary von Eclipse manuell auf das Board lade und per SSH starte, funktioniert alles (nachdem ich die Berechtigung per chmod geändert habe).
Wenn ich das c-File auf einer Linux-Maschine per Terminal kompiliere (Linaro-Cross-Compiler gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf), dann auf das Board lade und ausführen will, kommt "No such file or directory". Die Datei ist aber da (siehe Terminal-Ausschnitt)!

Code:

admin@NI-sbRIO-9607-01cbe9ce:~# ls -al
total 64
drwxr-xr-x    3 admin    administ       520 Apr 22 23:19 .
drwxr-xr-x    5 admin    administ       416 Oct 31 23:38 ..
-rw-r--r--    1 admin    administ       176 Mar  3  2017 .profile
-rwxr-xr-x    1 admin    administ     40706 Apr 23  2018 HelloWorld
-rwxr-xr-x    1 admin    administ     12676 Apr 22 23:11 HelloWorldLinux
drwxr-xr-x    2 admin    administ       304 Apr 22 22:49 ProjectFolder
-rw-r--r--    1 admin    administ         5 Apr 22 17:51 test.txt
admin@NI-sbRIO-9607-01cbe9ce:~# 
admin@NI-sbRIO-9607-01cbe9ce:~# 
admin@NI-sbRIO-9607-01cbe9ce:~# 
admin@NI-sbRIO-9607-01cbe9ce:~# ./HelloWorldLinux
-bash: ./HelloWorldLinux: No such file or directory

Hat jemand einen Tipp, woran das liegen könnte?

Danke euch!
Chill

KillerCow · 23. April 2018

Vielleicht passt das Binary nicht zum System, wobei ich nicht sicher bin, ob die Meldung dann nicht eine andere sein sollte. Testweise auch mal den kompletten Pfad angeben und nicht mit "./" arbeiten.

bog · 23. April 2018

der fehler ist typisch fuer eine falsche architektur, ist mir beim cross-compilen auf arm auch schon oft untergekommen. probier doch mal

Code:

$ file HelloWorldLinux

auf einem der linuxsysteme und schau dir an, ob das zu der architektur des boards passt.

chillking · 23. April 2018

Kompletten Pfad verwenden hat leider nichts gebracht.

Code:

[m@centos7 codes]$ file HelloWorldLinux
HelloWorldLinux: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, BuildID[sha1]=3c10453310db927b96f36773380e36463afdc6d4, not stripped

Zusätzlich noch:

Code:

[m@centos7 codes]$ readelf -h HelloWorldLinux
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x10311
  Start of program headers:          52 (bytes into file)
  Start of section headers:          11196 (bytes into file)
  Flags:                             0x5000400, Version5 EABI, hard-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         9
  Size of section headers:           40 (bytes)
  Number of section headers:         37
  Section header string table index: 36

Sollte laut Spezifikationen passen:

Falls es tatsächlich ein falscher Compiler ist, kann mir jemand den richtigen nennen?

EDIT: Könnte es auch sein, dass eine Library fehlt? Und gibts außer ldd eine Möglichkeit herauszufinden, welche fehltß (ldd gibts auf dem kleinen real-time-Linux nicht)

Hancock · 23. April 2018

Vergleich doch mal "file kaputt" mit "file funktionierend". Cross-Compilation ist nicht so einfach.

bog · 23. April 2018

das mit der lib ist moeglich... aber ich meine, normalerweise ist die fehlermeldung da eine andere. verifizieren wie hancock es sagt, alternativ kannst du mal posten wie du die binary kompilierst.
wenn es sich um shared libraries handelt, ist in der makefile typischerweise noch ein strip-befehl drin. den koenntest du in dem fall auskommentieren, und die benoetigten libraries sind dann im kompilat.
falls du das programm bloss ueber einzeiler per gcc kompilierst wirst du damit aber auch nichts veri- oder falsifizieren koennen.

chillking · 24. April 2018

Was meint ihr mit "vergleichen", es stehen andere Werte/Zeichen drin und die auf Linux kompilierte Datei ist ca 30% so groß wie die durch Eclipse kompilierte Datei.
Aber mit dem Inhalt kann ich nicht besonders viel anfangen.

Auf Linux habe ich per gcc-Befehl im Terminal kompiliert, verwende bisher kein Makefile.

EDIT: also in dem File für ARM steht teilweise welchen Compiler er benutzt hat und so weiter und zwischen drin auch mal:

short unsigned intshort int_IO_stdin_usedlong long unsigned intGNU C11 7.2.1 20171011 -march=armv7-a -mtune=cortex-a9 -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math -fno-stack-protector -ftls-model=initial-execunsigned char

Zumindest das ARM und Cortex A9 würden ja passen.
Den "HelloWorld"-String sehe ich auch.

Hancock · 24. April 2018

Die Ausgabe von

Code:

file <Datei>

vergleichen.

chillking · 24. April 2018

Ah okay, dabei kommt folgendes raus:

Code:

[m@centos7 codes]$ file HelloWorld
HelloWorld: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=c8a2c7d11b4c72f2ee72022dee404c40daf08b0f, not stripped
[m@centos7 codes]$ 
[m@centos7 codes]$ 
[m@centos7 codes]$ 
[m@centos7 codes]$ file HelloWorldLinux
HelloWorldLinux: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, BuildID[sha1]=3c10453310db927b96f36773380e36463afdc6d4, not stripped

"HelloWorld" ist von Eclipse, "HelloWorldLinux" auf Linux kompiliert.
Die GNU/Linux Version scheint auf der Linux-Maschine neuer zu sein.

mkossmann · 24. April 2018

Das "no such file or directory" kann auch eine shared library sein, die nicht gefunden wird. Schau dir das Programm mal mit ldd an.

chillking · 24. April 2018

Das habe ich auf dem Linux-PC bereits gemacht, jedoch kann ich da nicht das für ARM kompilierte Programm anschauen, und auf dem Real-Time-Linux gibt es ldd nicht.

Aber das können ja nur die Libraries sein, die ich im c-File eingebunden habe, oder?
Könnte ich dann versuchen die entsprechenden Dateien auf das Real-Time-Linux zu kopieren und den Pfad hinzuzufügen?

mkossmann · 24. April 2018

Im C File werden nur die Header ( mit z:b. Funktionsdeklarationen) der Library. benutzt Die Libraries selbst werden erst vom Linker eingebunden.
Du hast die Liste die dir das ldd auf dem Linux Entwicklungssystem liefert schon mit den auf dem Zynq vorhandenen Bibliotheken verglichen (Einschließlich Versionsnummern) ?

bog · 24. April 2018

^ genau das ist kritisch. bei dynamically linked binaries muss nicht nur die zielarchitektur der toolchain beim cross-compilen stimmen, sondern auch die versionsnummer (oder zumindest syntax) der versionen der libraries auf dem zielsystem.

praktisch gesehen wuerde ich fuer einen schnellen fix nach einem firmware update fuer das board, oder einer aelteren toolchain ausschau halten; da es mit eclipse zu funktionieren scheint wuerde ich mal nach einer fuer 2.6.16 schauen.

chillking · 24. April 2018

puh okay, also die auf und für die Linux Entwicklungsmaschine kompilierte Datei benötigt:

Code:

[m@centos7 codes]$ ldd HelloWorld
	linux-vdso.so.1 =>  (0x00007ffda0db1000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f36d6cdc000)
	/lib64/ld-linux-x86-64.so.2 (0x000055a8aab7d000)
[1]+  Done                    gedit Makefile

Auf der Entwicklungsmaschine ist:

Code:

[m@centos7 codes]$ ldconfig -p | grep libc.so
	libc.so.6 (libc6,x86-64, OS ABI: Linux 2.6.32) => /lib64/libc.so.6
	libc.so.6 (libc6, OS ABI: Linux 2.6.32) => /lib/libc.so.6

Die "linux-vdso" findet er nicht und die ld-linux-x86-64 kann ich mir auf dem Zynq sparen, nehme ich mal an.

Auf dem Zynq ist:

Code:

admin@NI-sbRIO-9607-01cbe9ce:~# ldconfig -p | grep libc.so
	libc.so.6 (libc6,soft-float, OS ABI: Linux 3.14.3) => /lib/libc.so.6

Zumindest die hat schonmal eine andere Version...heißt ich muss jetzt schauen, dass ich auf beiden Systemen dieselbe Version habe?

Auf dem Board ist die aktuelle Firmware installiert.

Ergänzung (24. April 2018)

Ich habe soeben statt dem Cross Compiler "gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf" den hier "gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabi" benutzt und jetzt scheint es zu funktionieren:

Code:

admin@NI-sbRIO-9607-01cbe9ce:~# ./a.out
!!!Hello World!!!
admin@NI-sbRIO-9607-01cbe9ce:~# ldconfig -p | grep libc.so
	libc.so.6 (libc6,soft-float, OS ABI: Linux 3.14.3) => /lib/libc.so.6

Code:

[mkaupert@mkaupertcentos7 codes]$ ldconfig -p | grep libc.so
	libc.so.6 (libc6,x86-64, OS ABI: Linux 2.6.32) => /lib64/libc.so.6
	libc.so.6 (libc6, OS ABI: Linux 2.6.32) => /lib/libc.so.6

Die Library ist aber immernoch eine andere...

Ergänzung (24. April 2018)

Ist der Unterschied zwischen den Compilern mit und ohne "hf" tatsächlich die Nutzung einer FPU?

Hancock · 24. April 2018

Ja. hf = Hard float, wenn du das auf nem ARM ohne FPU ausführst, muss der Kernel jeden FP-Befehle emulieren => Schneckentempo. Wenn du ne FPU hast (Zync hat glaub eine) => Rakete.

chillking · 24. April 2018

Ich bin davon ausgegangen, dass der Zynq eine FPU hat.
Aber gerade dann sollte der hf-Compiler doch funktionieren oder?

EDIT: Single and double precision Vector Floating Point Unit (VFPU)

Hancock · 24. April 2018

Das Problem ist, dass dann andere Bibliotheken geladen werden (/usr/lib/arm-linux-gnueabihf). Wenn die nicht da sind, Pech gehabt.

Grund: Calling Convention. floats werden mit hardfp in den Registern übergeben. In softfp auf dem Stack. Falls du defintiv hardfp willst: -mfloat-abi=softfp -mfpu=vfp als Flags beim Compilieren angeben.

chillking · 25. April 2018

Hancock schrieb:
Falls du defintiv hardfp willst: -mfloat-abi=softfp -mfpu=vfp als Flags beim Compilieren angeben.

Danke, das hat funktioniert :-)

Dann schau ich mich jetzt mal um, wie ich das Makefile anlegen muss und welche Bibliothek ich für C++ brauche(War nur zu blöd zum Tippen...)

Hancock · 25. April 2018

Falls der Zynq NEON kann, natürlich auch mit -mpfu=neon, dann geht's noch mal etwas schneller.

chillking · 25. April 2018

Laut Zynq-7000 All Programmable SoC Data Sheet hat er VFPU und NEON.

C Fehler: No such file or directory, obwohl die Datei da ist.

Lieutenant

Lt. Commander

Ensign

Lieutenant

Captain

Ensign

Lieutenant

Captain

Lieutenant

Commander

Lieutenant

Commander

Ensign

Lieutenant

Captain

Lieutenant

Captain

Lieutenant

Captain

Lieutenant

Ähnliche Themen