libjpeg.so.8 wird gebraucht. Nachinstallation möglich? Wie?

[Dengo]

Hallo Forum,

ich bräuchte das Paket libjpeg.so.8, aber in den aktuellsten Debian-Versionen wird inzwischen libjpeg62-turbo an dieser Stelle eingesetzt.

Ist es möglich, dieses Paket auf Debian 12 nachzuinstallieren? Wo kann ich es beziehen und wie installieren?

Ich verwende Debian 12 und Mate auf meinem Thinkpad x220.

Warum ich das Paket brauche schäme ich mich ein wenig, um es zu sagen, denn ich mache ungern Ausnahmen in Richtung unfreien Programmen. Wir Sprachwissenschaft fehlt mir ein Gesamtwerkzeug für Untersuchungen gesprochener Sprache im Bereich "Qualitative Inhaltsanalyse". Daher würde ich nun das unfreie Programm F4 einsetzen.

F4 soll angeblich auf unterschiedlichen GNU/Linux-Distributionen funktionieren, auch unter "Debian 11 oder neuer". Die Kurzanleitung > nopasta

Lade ich die Testversion für Linux herunter, entpacke es und führe es aus, so wird eine Fehlermeldung ausgegeben:

Code: Alles auswählen

dengo@debian:~/Downloads/f4$ ./linux_start.sh 
./64-bit/f4: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory

Hier im Forum bin ich auf diesen Beiträge gestoßen, konnte aber nicht weiter kommen:
"libjpeg.so.8 nachinstallieren" viewtopic.php?t=160542
"Unterschiede zwischen libjpeg8/62-Paketen?" viewtopic.php?f=25&t=158034

Der daraus abgeleiteten Versuch, es auf dieser Weise zu lösen, führte zu neuen Paket-Aufforderungen:

Code: Alles auswählen

 sudo dpkg --force-all -i libjpeg8_8d-1+deb7u1_amd64.deb 
dpkg: Vor-Abhängigkeitsproblem betreffend libjpeg8_8d-1+deb7u1_amd64.deb, welches libjpeg8:amd64 enthält:
 libjpeg8 hängt (vorher) von multiarch-support ab
  multiarch-support ist nicht installiert.

dpkg: Warnung: Vor-Abhängigkeitsproblem wird ignoriert!
(Lese Datenbank ... 619269 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von libjpeg8_8d-1+deb7u1_amd64.deb ...
Entpacken von libjpeg8:amd64 (8d-1+deb7u1) ...
dpkg: libjpeg8:amd64: Abhängigkeitsprobleme, wird aber trotzdem wie gefordert konfiguriert:
 libjpeg8:amd64 hängt ab von multiarch-support; aber:
  Paket multiarch-support ist nicht installiert.

libjpeg8:amd64 (8d-1+deb7u1) wird eingerichtet ...

Versuche ich nun das Programm zu starten, kommt folgende Meldung vor:

Code: Alles auswählen

dengo@debian:~/Downloads/f4$ ./linux_start.sh 
./64-bit/f4: error while loading shared libraries: libicuuc.so.70: cannot open shared object file: No such file or directory

Da ich mehr als ein System Debian 12 pflege, kann ich von einem zum anderen wechseln, sollte ich das eine durch ungeschickte Aktionen verbockt haben.

Wie könnte ich das Problem in den Griff bekommen?

Ich bedanke mich im Voraus!

Viele Grüße

dengo

[rhHeini]

Der erste Ansatz wäre mal den Multiarch-Support einzurichten. Hört sich kompliziert an, ist aber kein grosses DIng.

Code: Alles auswählen

# dpkg --add-architecture i386 
# apt update 
# apt upgrade 
# dpkg --print-foreign-architectures

Schau mal was dann passiert.

Edith: nach dem Nachgraben von wanne tief in den Details tue ich das mal durchstreichen.

[MSfree]

In dem runterladbaren Linuxarchiv (tar.gz) ist die libjpeg.so.8 vorhanden. Du brauchst da also nichts nachzuinstallieren.

Es kommt auch ein linux_start.sh mit, das die nötige Umgebung schaffen sollte, damit die Bibliotheken gefunden werden.

Ein README_de ist abenfalls dabei, in das man durchaus reinschauen darf.

[wanne]

Es kommt auch ein linux_start.sh mit, das die nötige Umgebung schaffen sollte, damit die Bibliotheken gefunden werden.

Sollte. Aber nicht tut...

Zum eigentlichen Thema:
Die 8er Version der libjpeg ist 14 Jahre alt! Das Paket war für wheezy (Debian 7 wir sind bei Debian 12.) gedacht und wurde dann zugunsten einer neueren Version aufgegeben.
Damit zerschießt du dir mit ziemlicher Sicherheit das System:

Code: Alles auswählen

sudo dpkg --force-all -i libjpeg8_8d-1+deb7u1_amd64.deb 

Wie mit quasi allen Kommandos, die dpkg oder --force oder ähnliches als root enthalten. Wenn apt sich weigert irgend was zu installieren dann hat das ziemlich sicher seinen Grund. Und bevor du den nicht verstanden hast, solltest du da nicht mit Gewalt noch mehr kaputt machen!

Daher würde ich nun auf das unfreie Programm F4 einsetzen.

Das Ding war bei mir unten durch als es anfing per JS-"dauerschleife" den Downlaod um 120s zu verzögern. Dass sie ihren LD-Pfand nicht setzen können und 15 Jahre alte Libus in neu geschriebener Software verwenden rundet das ganze ab.
Das Ding benutzt cuda über nodejs ist in den Quellen. Kannst du damit (als root) installieren, wenn du non-free aktiviert hast.

Code: Alles auswählen

apt install nsight-compute

Rundet das ganze für mich als eine schönes Studentenprojekt ohne weitere Programmierkenntnisse ab.
Starten kannst du es dann mit:

Code: Alles auswählen

export LD_LIBRARY_PATH="./64-bit/lib/:/usr/lib/nsight-compute/host/linux-desktop-glibc_2_11_3-x64/"
./linux_start.sh

Der erste Ansatz wäre mal den Multiarch-Support einzurichten.

Achtung: Das Paket, dass er da installieren will ist jahrzehnte alt. Da hat das mit Multiarch noch deutlich anders funktioniert. Deswegen die komische Fehlermeldung. Hier geht es um 64Bit-Pakete auf nem 64-Bit System. Es braucht kein Multiarch. Das Paket ist nur so alt, dass es komische Workarounds (die längst nicht mehr nötig sind) für 64Bit-Support nach sich ziehen will.

[Dengo]

Danke schön für die Unterstützung!

Wanne schrieb:

Das Ding benutzt cuda über nodejs ist in den Quellen. Kannst du damit (als root) installieren, wenn du non-free aktiviert hast.

Ich habe nodejs installiert, anschließend auch nsight-compute.

Dann als normaler Nutzer den Befehl:

Code: Alles auswählen

export LD_LIBRARY_PATH="./64-bit/lib/:/usr/lib/nsight-compute/host/linux-desktop-glibc_2_11_3-x64/"

Wenn ich nun, ohne das System neu gestartet zu haben, F4 öffnen möchte, kommt die unveränderte Fehlermeldung bezüglich libjpeg.so.8:

Code: Alles auswählen

$ ./linux_start.sh 
./64-bit/f4: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory

Habe ich was übersehen?

[wanne]

Wenn ich nun, ohne das System neu gestartet zu haben, F4 öffnen möchte, kommt die unveränderte Fehlermeldung bezüglich libjpeg.so.8:

Ich würde fast wetten, das du dir die Antwort selbst gegeben hast. Das gehört zusammen.
Die bash führt Programme aus. Man kann die nicht einfach in der Mitte zerteilen. Etwas schöner, damit man keine Zeilenumbrüche mit kopieren musst:

Code: Alles auswählen

LD_LIBRARY_PATH="./64-bit/lib/:/usr/lib/nsight-compute/host/linux-desktop-glibc_2_11_3-x64/" ./linux_start.sh

Das mitgelieferte linux_start.sh ist offensichtlich kaputt. Es setzt die passenden variable LIBS für LD_PRELOAD um sie dann nicht zu preloaden.
Du kannst es reparieren indem du entweder dasda:

Code: Alles auswählen

export LD_LIBRARY_PATH="$ROOT/64-bit/lib/:/usr/lib/nsight-compute/host/linux-desktop-glibc_2_11_3-x64/"

in die erste Zeile unter derda einfügst:

Code: Alles auswählen

START_PATH=$ROOT/64-bit

Oder halt indem du LD_LIBRARY_PATH von Hand vor den Befehl setzen.

Ich habe den Befehl mit 2 Zeilen genommen, weil der geübtere Leser die passende Zeile ins script einfügen kann und der etwas ungeübtere trotzdem einfach kopieren und einfügen kann.

[Dengo]

Wanne schrieb:

Das mitgelieferte linux_start.sh ist offensichtlich kaputt. Es setzt die passenden variable LIBS für LD_PRELOAD um sie dann nicht zu preloaden.
Du kannst es reparieren indem du entweder dasda:

export LD_LIBRARY_PATH="$ROOT/64-bit/lib/:/usr/lib/nsight-compute/host/linux-desktop-glibc_2_11_3-x64/"

in die erste Zeile unter derda einfügst:

START_PATH=$ROOT/64-bit

Ich habe die export-Zeile entsprechend in die Startdatei linux_start.sh geschrieben.

Nun kann ich F4 aus seinem aktuellen Verzeichnis so starten, ohne sichtbare Fehlermeldungen:

Code: Alles auswählen

$ ./linux_start.sh 

Gebe ich stattdessen die Gesamtzeile ein, so startet ebenfalls das Programm, aber es werden Meldungen in der bash ausgegeben:

Code: Alles auswählen

$ LD_LIBRARY_PATH="./64-bit/lib/:/usr/lib/nsight-compute/host/linux-desktop-glibc_2_11_3-x64/" ./linux_start.sh

(f4:3799713): GLib-GObject-WARNING **: 12:58:30.923: ../../../gobject/gsignal.c:2772: instance '0x7952d30' has no handler with id '1027'

(f4:3799713): GLib-GObject-WARNING **: 12:58:30.925: ../../../gobject/gsignal.c:2772: instance '0x7952e10' has no handler with id '1204'

(f4:3799713): GLib-GObject-WARNING **: 12:58:30.927: ../../../gobject/gsignal.c:2772: instance '0x7952ef0' has no handler with id '1381'

(f4:3799713): GLib-GObject-WARNING **: 12:58:30.927: ../../../gobject/gsignal.c:2772: instance '0x7c24090' has no handler with id '1558'

(f4:3799713): GLib-GObject-WARNING **: 12:58:30.928: ../../../gobject/gsignal.c:2772: instance '0x7c24170' has no handler with id '1735'

(f4:3799713): GLib-GObject-WARNING **: 12:58:30.929: ../../../gobject/gsignal.c:2772: instance '0x7c24250' has no handler with id '1912'

(f4:3799713): GLib-GObject-WARNING **: 12:58:30.930: ../../../gobject/gsignal.c:2772: instance '0x7c24330' has no handler with id '2089'

(f4:3799713): GLib-GObject-WARNING **: 12:58:30.931: ../../../gobject/gsignal.c:2772: instance '0x7c24410' has no handler with id '2266'

(f4:3799713): GLib-GObject-WARNING **: 12:58:30.932: ../../../gobject/gsignal.c:2772: instance '0x7952c50' has no handler with id '850'

(f4:3799713): GLib-GObject-WARNING **: 12:58:30.933: ../../../gobject/gsignal.c:2772: instance '0x7952b70' has no handler with id '673'

(f4:3799713): GLib-GObject-WARNING **: 12:58:30.934: ../../../gobject/gsignal.c:2772: instance '0x7952a90' has no handler with id '490'

In den nächsten Tagen werde ich das Programm testen, um zu sehen, ob es ausreichend gut funktioniert.

Schön, dass es nun startet! Bin froh und dankbar!

Viele Grüße

dengo

[wanne]

Gebe ich stattdessen die Gesamtzeile ein, so startet ebenfalls das Programm, aber es werden Meldungen in der bash ausgegeben:

Gefühlt ziemlich üblich bei GTK-Anwendungen. Hintergrund ist wohl dass viele Entwickler nicht sicherstellen ob passende Objekte existieren sondern einfach die Aktion ausführen. So werden z.B. diverse Handler für X11 am Ende aufgeräumt. Auch wenn man die nie genutzt hat, weil man unter wayland läuft, gibt dann eine passende Fehlermeldung dass das nicht aufgeräumt werden kann. Schadet aber auch nicht, sodass das bei den meisten Programmieren wenig Priorität hat.