Hallöchen,
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?
Danke,
ts
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".
Thorsten S. schrieb:> 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.
Niklas G. schrieb:> 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".`
Jack V. schrieb:> 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.
Danke für die Hilfe, Problem solved.
Niklas G. schrieb:> Wie das jetzt?
Statisch gebautes 32Bit-Binary auf’m 64Bit-System, wohl.
Schotter schrieb:> 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.
Jack V. schrieb:> Statisch gebautes 32Bit-Binary auf’m 64Bit-System, wohl.
Ja, aber das sollte man prinzipiell schon auch starten können. Braucht
ja nichtmal den dynamischen Linker. 32bit Support im Kernel deaktiviert?
Niklas G. schrieb:> Schotter schrieb:>> Problem solved.>> Wie das jetzt?
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.
Niklas G. schrieb:> Ja, aber das sollte man prinzipiell schon auch starten können. Braucht> ja nichtmal den dynamischen Linker. 32bit Support im Kernel deaktiviert?
Nope, es läuft [AlmaLinux8](https://almalinux.org/), RHEL-Klon.
Jack V. schrieb:> Noch besser ist aber im Fall proprietärer Software, den Support ihres> Anbieters zu kontaktieren.
Da kommt als erstes die Frage, ob auch RHEL oder SuSE im Einsatz ist.
Das muss ich verneinen und dann heißt's "Pech gehabt".
Schotter schrieb:> $ 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.
Thomas F. schrieb:> 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.