Hi, ich habe folgendes Problem: Ich möchte eine Datei ausführen, Ubuntu sagt aber, das sie nicht gefunden wird. Hier die Shell:

torsten@gretel:~$ /tmp/I 
bash: /tmp/I: No such file or directory

torsten@gretel:~$ ls /tmp/I 
/tmp/I

torsten@gretel:~/Desktop/SoftwareProjekte/4k-Playground$ file /tmp/I 
/tmp/I: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), stripped

torsten@gretel:~/Desktop/SoftwareProjekte/4k-Playground$ wc -c /tmp/I
3920 /tmp/I

Es handelt sich um meine Gehversuche in Richtung 4k Intros. Unter Suse kann ich das Programm kompilieren und ausführen. Bei einer früheren Version klappte das Ausführen, unter 11.10 aber nicht mehr. Hat jemand Erfahrungen damit?

Hast du´s schon mal mit

1
2

chmod +x /tmp/I
/tmp/I

versucht?

Ja, ausführbar ist die Datei.

1
2

ls -ls /tmp/I 
4 -rwxrwxr-x 1 torsten torsten 3920 2012-04-24 21:21 /tmp/I

Servus,

kannst du die Binary mal hier reinstellen, damit man sich das anschauen kann? Die Chancen steigen dann, dass dem ein oder anderen etwas auffällt.

Hier ist sie

Bei mir sagt er zu dieser Datei:

track@lucid:~$ Downloads/I
bash: Downloads/I: Kann die Datei nicht ausführen.
track@lucid:~$ gdb Downloads/I
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 ...
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
"/home/track/Downloads/I": not in executable format: File format not recognized
(gdb)  

... allerdings auf einer 32-Bit-Kiste. Wie hast Du das denn kompiliert ? - ( was sagen diese Befehle bei Dir ? )

LG,

track

Ist dein Ubuntu zufällig 32 Bit?

Ich habe ein 64bit Ubuntu.

Kompiliert habe ich etwa so:

1
2

gcc -Os -fomit-frame-pointer  -fno-inline  -c raymarching.c -o main.o 
ld -dynamic-linker /lib/ld-linux.so.2 main.o /usr/lib/libSDL.so /usr/lib/libSDL_gfx.so -o s

GDB sagt:

1
2
3
4

Code(gdb) run
Starting program: /tmp/I 
/bin/bash: /tmp/I: No such file or directory
During startup program exited with code 127.

Die Binary ist defekt. Finde deinen Kompilier aufruf auch sehr merkwürdig, aber kann nicht wirklich sagen, ob er falsch ist oder nicht. Aber '-o' vom gcc hat bereits einen Linking-Step, insofern habe ich den Eindruck, hier wird zweimal gelinkt.

Edit: Hat sich erledigt, ich habe das '-c' Flag übersehen.

Die Quelldate hat keine richtige main()-Methode, damit die binary kleiner ist. Stattdessen eine _start()-Methode. Ich kann mir vorstellen, dass die Datei defekt ist, Aber selbst wenn die Datei defekt ist, warum sagt mir die bash, das die Datei nicht gefunden wird?

wookenny schrieb:

Die Quelldate hat keine richtige main()-Methode, damit die binary kleiner ist. Stattdessen eine _start()-Methode. Ich kann mir vorstellen, dass die Datei defekt ist, Aber selbst wenn die Datei defekt ist, warum sagt mir die bash, das die Datei nicht gefunden wird?

Die Fehlermeldung könnte insofern irreführend sein, dass ggf. eine andere Datei gemeint ist und Du "/tmp/I" nur siehst, weil es das Programm ist, in dem der Fehler auftritt.

Ciao

robert

wookenny

Aber selbst wenn die Datei defekt ist, warum sagt mir die bash, das die Datei nicht gefunden wird?

Die Fehlermeldung kommt oft, wenn man versucht eine defekte Binary auszuführen. Mit 'strace' kann man meistens herausfinden, woher das kommt.

Auf meinem System ist die Fehlermeldung auch sinniger:

zsh: accessing a corrupted shared library: ./I

Die Quelldate hat keine richtige main()-Methode,

Ach, linkst du deshalb mit ld statt mit gcc? Wenn es dir um die Größe geht, musst du wohl direkt Assembler schreiben.

Bin bei der Arbeit, an einem Suse Rechner. Hier kann ich diese Datei auch nicht ausführen. Das liegt aber daran, dass die Pfade falsch sind, die beim Linken benutzt wurden.

Ich teste später dann mal strace unter Ubuntu.

Vielen Dank für den Hinweis auf strace, mit der Ausgabe kann ich weiter an den Ursachen forschen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

strace /tmp/I 

execve("/tmp/I", ["/tmp/I"], [/* 45 vars */]) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7515c80000
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
close(3)                                = 0
munmap(0x7f7515c80000, 4096)            = 0
exit_group(1)                           = ?

Ja, der execv-Befehl schlägt schon fehl. Ich nehme an, dass ENOENT als Rückgabewert einfach falsch ist. Auf meinem System kommt an der Stelle auch ELIBBAD, was schon sinniger ist.

Jedenfalls, ich denke, du solltest schon C idiomatisch schreiben, sprich eine Main-Methode haben. Die Binary-Größe wird dadurch auch nicht nennenswert beinflusst, so dass der ganze Ansatz schon nicht so zielführend ist.