folgendes Problem. Es gibt da ein Programm, das sich mit
1
No such file or directory
verabschiedet. Normalerweise wird es aus einer GUI heraus ausgeführt, d.h. an einem falschen Aufruf liegt es nicht.
Eine ähnliche Situation hatte ich schon einmal, dabei hat mir strace die Sicht verstellt, denn die ausgeführte "Anwendung" war nur ein Skript, dass nach ksh gefragt hat, was nicht installiert war. -> Gleicher Fehler.
Aber jetzt handelt es sich definitiv um ein kompiliertes Programm und ich dachte mit strace würde ich herausbekommen auf welche Datei zugegriffen werden soll. Klappt aber nicht. (verbose liefert auch nicht mehr.)
1
straceprogram
2
execve("/path/to/the/executable/bin/program",["program"],0x7ffd5e62b230/* 67 vars */)=-1ENOENT(Nosuchfileordirectory)
3
strace:exec:Nosuchfileordirectory
4
+++exitedwith1+++
Ich vermute es fehlt irgendein Paket.
Hat jmd weitere Ideen, wie ich der Datei/Bibliothek auf die Schliche komme?
Wahrscheinlich ist die Programmdatei gar nicht auf dem System ausführbar, z.B. weil sie für eine andere Architektur kompiliert wurde. Ggf. hilft das installieren von 32/64 bit libraries für die benötigte Architektur.
Benutz mal "file programmdatei" und "ldd programmdatei" und "objdump -f programmdatei".
Hat jmd weitere Ideen, wie ich der Datei/Bibliothek auf die Schliche
komme?
Mit den Daten, die du rauszensiert hast. Wenn man wüsste, um welches Programm es denn geht, könnte man schauen, wovon es abhängt und wo es seine Komponenten erwartet.
Wahrscheinlich ist die Programmdatei gar nicht auf dem System
ausführbar, z.B. weil sie für eine andere Architektur kompiliert wurde.
Ggf. hilft das installieren von 32/64 bit libraries für die benötigte
Architektur.
Darauf wird es wohl hinauslaufen. Ich musste der Datei auch erst noch etwas hinterherlaufen, weil es sich um einen SymLink handelte. Aber nachdem ich den aufgelöst hatte, konnte ich mir sicher sein, dass die Ausgaben passen.
Benutz mal "file programmdatei" und "ldd programmdatei" und "objdump -f
programmdatei".`
Mit den Daten, die du rauszensiert hast. Wenn man wüsste, um welches
Programm es denn geht, könnte man schauen, wovon es abhängt und wo es
seine Komponenten erwartet.
Würde es sich um ein Open Source Programm handeln, hätte ich das schon mit angegeben.
Würde es sich um ein Open Source Programm handeln, hätte ich das schon
mit angegeben.
Auch bei Closed Source darf man in der Regel Namen, Pfade und weitere Informationen angeben, um den Leuten die Unterstützung zu erleichtern. Noch besser ist aber im Fall proprietärer Software, den Support ihres Anbieters zu kontaktieren.
32-Bit Bibliotheken nachinstalliert. Jetzt lässt es sich immerhin ausführen. Die "GUI" wirft noch die gleiche Fehlermeldung, aber da vermute ich jetzt eher nicht erfüllte Abhängigkeiten. Ein yum install *.i686 wollte ich nicht lostreten. Jetzt wird's eben fisselig.
$ file program
program: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2,
BuildID[sha1]=f6aaff89144be508306dc56d14f4807ab997a953, for GNU/Linux
2.6.32, stripped
$ ldd program
not a dynamic executable
Die Ausgabe finde ich merkwürdig. file meint, es sei dynamisch gelinkt, ldd sagt genau das Gegenteil.
ldd schreibt das immer, wenn er mit dem Programm nichts anfangen kann, also auch wenn - wie hier- ein 64Bit-ldd ein 32Bit-Programm bekommt. file hat da einen wesentlich breiteren Blickwinkel und kennt mehr Varianten.
ldd schreibt das immer, wenn er mit dem Programm nichts anfangen kann,
also auch wenn - wie hier- ein 64Bit-ldd ein 32Bit-Programm bekommt.
file hat da einen wesentlich breiteren Blickwinkel und kennt mehr
Varianten.
Bei mir funktioniert es sowohl mit 32- als auch mit 64-Bit-Programmen.
