AppImage und Pfadangaben in AppRun
Hallo,
ich weiß, ich müßte das eigentlich im Bugtracker schreiben, aber ich kann kein Englisch und vielleicht braucht die Information jemand anderes, dem es ähnlich geht.
Da ich immer noch die Version 2.3.2 brauche und die Sache mit dem Dualinstallieren aus dem Repos so eine Sache ist, habe ich mich mal fürs AppImage entschieden.
Aber, keine Tonausgabe unter Jack. Von der Shell aus ausgerufen:
~> MuseScore-2.3.2-x86_64.AppImage -a jack
/tmp/.mount_z2mAuS/AppRun: Zeile 15: ldconfig: Kommando nicht gefunden.
Also da mal reingeschaut (für Unbedarfte: das AppImage ist eine gepackte Datei, die zur Laufzeit geöffnet wird und sozusagen ein Dateisystem mit Dateien enthält, wie ein CD-ISO).
Da wurde der gern gemachte Fehler begangen, das die Systempfade nicht zur Verfügung stehen:
if ldconfig -p | grep libjack.so.0 > /dev/null 2>&1; then
Ja, den Befehl gibt es da nicht, der liegt (bei mir) unter /sbin.
Also das Image ausgepackt in AppRun die Zeile auf
if /sbin/ldconfig -p | grep libjack.so.0 > /dev/null 2>&1; then
und schon funktioniert es.
Besser wäre natürlich am Anfang der Datei ein:
PATH=/usr/local/bin:/usr/share/bin:/usr/bin:/bin:/sbin
Achja, bei den Pfaden viel mir noch das 'lib' statt 'lib64' auf. Ich habe mal ein Binary überprüft. Es ist 64 Bit. Es macht einem nur etwas unruhig, aber
libs="${APPDIR}/lib"
besagt, das die im System installierten Libarys nicht verwendet werden, von daher.
Also nur die fehlende PATH-Variable oder (schlechter:) die Angabe mit Pfad von benötigten Systembefehlen. Weil ldconfig könnte bei anderen Linuxsystemen auch woanders liegen.
Grüße
Tux
Comments
Da solche Bugs üblicherweise früher oder später gefixt werden, setze ich da gerne einen symbolischen Link. Auf diese Weise kann ich zunächst unaufwändig testen, ob's funktioniert, ohne dass ich im Quellcode oder nicht dokumentierten Konfigurationsdateien herum basteln muss. Und die Paketkonsistenz wird nicht angetastet.
Grundsätzlich ziehe ich immer in Erwägung, dass ich nicht der Einzige bin, der dieses Problem hat und dass es deshalb schon bemerkt wurde. Sollte ich doch der Einzige sein, liegt es wohl eher an meinem ganz "individuell gepflegtem" System. Referenz wäre dann ein sauberes Livesystem, in dem ich mal schnell das appImage installiere, um zu sehen, ob's dort geht.
Manchmal muss man vllt. rabiater hin fassen, damit's läuft. ;)
Antwort auf Da solche Bugs üblicherweise… von EsDur
Hallo,
nunja, das bedarf es hier nicht, ist ja nur eine Kleinigkeit, die aber den ein oder anderen zur Verzweiflung bringen kann (ich glaube das Netz ist voller Fragen, warum mein cron-Skript nicht läuft). Seit die Distributoren vor Jahren standardmäßig /sbin nicht mehr in der PATH-Variable zu nehmen, habe ich Anfangs auch ziemlich als erstes das geändert. Ich vermute, der Päckchenbauer auch.
Da es sich um einer alten Version handelt, denke ich nicht, daß das noch geändert wird. Betrifft nur jene, die a) Linux verwenden und b) jackd benutzen wollen und c) /sbin nicht im Pfad haben.
Bevor ich einen Symlink setze, fix ich lieber den Fehler. Noch dazu bei einem Paket, welches ich auf dem System nicht mehr installieren werde.
Habs hier erwähnt, falls noch jemand über das Problem stolpern sollte, welches im Zuge des Fortschreitens von Version 3 immer geringer werden wird.
Grüße
Tux