staging.inyokaproject.org

Also wenn Du Dich um Sicherheitslücken sorgst, dann kannst du gegen Gebühr, noch fünf weitere Jahre Sicherheitsupdates für Bionic bekommen! Ubuntu bietet das an.

Edit: Ich sehe gerade, für Privatleute ist das kostenlos! Man muss sich nur registrieren:

• Wiki-Artikel Ubuntu Pro

• Ubuntu-Pro-Page

Hab' aber nicht verstanden, wozu dieses optionale Paid-Upgrade nach einem Jahr ist.

• Ubuntu Pro wurde gerade erst eingeführt (Jan 2023), hier zu lesen.

• Ubuntu Advantage gibt's dadurch nicht mehr.

..hey, vielleicht mache ich das!

Mein System läuft einwandfrei und ich hätte schon ganz gerne, dass das so bleibt. 😀

Krieg ich ich jetzt ein Appimage oder nicht?

whocares02 schrieb:

Krieg ich ich jetzt ein Appimage oder nicht?

Wenn Du es dir selbst baust. Ich baue keine Appimages.

Warum denn nicht? Du hast es doch schon kompiliert. Brauchst es doch jetzt nur noch in so 'ne Appimage-Datei packen.

Alternativ: Kannst Du nicht einfach den Ordner komprimieren und hier hochladen? Damit wäre mir schon geholfen.

bump

Ich vermute, du hast eine falsche Vorstellung von den Möglichkeiten.

Ein Programm aus den Quelltexten zu erstellen, ist etwas anderes als ein Appimage (oder ein anderes Containerformat) zu bauen. Denn da müssen die benötigten Libs statisch eingebunden werden, was eine andere Vorgehensweise erfordert.

Und Verzeichnis hochladen hilft auch nicht. Da hast du dann eine Binärdatei, die gegen aktuellere Lib Versionen gelinkt ist, als auf deinem System vorhanden. Beim Laden eines Programms werden meist nur Libs mit neuerer Versionsnummer akzeptiert, sofern nicht die Major Version (Vorkomastelle) betroffen ist. Dazu kommt noch, dass einige Programme explizit die Lib nach ihrer Versionsnummer befragen. Ich mache das beim FLTK Toolkit auch manchmal, wenn mein Programm auf eine bestimmte Erweiterung angewiesen ist, von der ich weiß, das sie erst ab einer bestimmten Version vorhanden ist.

Ja, da stößt mein Linux-Wissen an Grenzen. Dass mit dem ganzen Linking habe ich nie verstanden. Jetzt ist es aber nun so, dass es sich bei der betroffenen Software nicht um eine große Applikation, sondern eine Sammlung mehrerer kleiner Cmd-Line-Programme handelt. Ich kann mir gut vorstellen, dass die einzelnen Programme (jew. eine Executable) alles enthalten, um zu laufen...wenn sie denn erst einmal kompiliert wurden.

Ich kann mir gut vorstellen, dass die einzelnen Programme (jew. eine Executable) alles enthalten, um zu laufen...wenn sie denn erst einmal kompiliert wurden.

Das ist leider selten der Fall. Irgendwelche Bibliotheken werden eigentlich immer benötigt. Ich versuche das mal vereinfacht darzustellen.

Ein Programm benötigt z.B. eine Funktion aus libcrypt. Wenn diese Lib auf dem System vorhanden ist, wird sie in den Speicher geladen und das Programm kann darauf zugreifen. Ist sie nicht vorhanden, scheitert der Programmstart.

Wird jetzt ein weiteres Programm gestartet, welches ebenfalls libcrypt benötigt, stellt das System fest, das die Lib bereits geladen ist und macht diese dann auch dem neuen Programm bekannt. Die Bibliothek liegt also nur einmal im Speicher, kann aber von mehreren Programmen genutzt werden. Bei Linux heißen sie deshalb auch "shared libraries" und haben die Endung ".so" (bei Windows .dll).

Das hat einige Vorteile: Es spart Speicherplatz und macht die Programmdateien kleiner. Und bei einer Fehlerhafen Bibliothek muss nur die korrigierte Version ausgetauscht werden. Eine erneute Übersetzung der Anwendungsprogramme ist nicht erforderlich.

Es gibt natürlich auch Fälle, wo das nachteilig ist. Also wenn man z.B. für Service Zwecke ein Programm benötigt, das ohne Neuübersetzung auf verschiedenen Systemen direkt einsatzfähig ist. Aber wenn man das zum Standard macht, hebelt man die eigentlichen Vorteile von Linux aus (s.o.).

Man kann natürlich auch statisch linken. Der Linker fügt alle Objektdateien (.o), die man ihm übergibt, zusammen. Man kann den Linker aber auch dazu veranlassen, fehlende Funktionen in einer Archivdatei (.ar) suchen zu lassen. Dann sind diese auch in der ausführbaren Datei vorhanden. Aber wie man von einer .so-Datei zu einer .ar-Datei kommt, kann ich nicht sagen.

Das statische Linken benutze ich für meine Programme, die mit einer Entwicklerversion des FLTK Toolkits erstellt wurden. Dies ist möglich, da ich den kompletten Quelltext habe und notwendig ist es, weil es sonst Komplikationen mit libfltk* des Systems gäbe. Das Problem dabei ist, dass sich bei unterschiedlichen Versionen die Funktionsschnittstellen unterscheiden können. Wenn man das nicht beachtet, bekommt man unerklärliche Abstürze. Anfangs hatte ich das nicht beachtet und bin auch prompt auf die Nase gefallen.

Edit: typo

Dakuan schrieb:

Das ist leider selten der Fall. Irgendwelche Bibliotheken werden eigentlich immer benötigt.

Hier mal die build-dependencies:

Build-Depends: debhelper (>= 12), qtbase5-dev, qttools5-dev-tools, libglib2.0-dev, libmad0-dev, libgcrypt20-dev, libusb-1.0-0-dev, libid3tag0-dev, libtag1-dev

Was trollsportverein da kompiliert hat ist also gegen die jeweiligen Versionen dieser Abhängigkeiten (debhelper mal ausgenommen, das dürfte hier nicht relevant sein) auf seinem System gebaut und die werden dann auch in den Versionen benötigt, die er auf seinem System hat.

Vielen Dank für die Erklärung. Das hilft mir grundsätzlich. Das defekte libgcrypt-package aus Bionic bekomme ich aber natürlich so nicht repariert. System-Upgrade auf Kinetic, wegen EINEM Paket, nee, das mach' ich nicht. Da tausche ich ein Problem gegen fünf neue (mindestens).

Was wäre mit einem Kompile-Vorgang unter Debian? Ubuntu und Debian sind sich doch so ähnlich. Meinem libgcrypt-package fehlt ja "nur" ide .pc-Datei, so dass der Kompiler die Bibliothek nicht findet. Ob das Linken zur Laufzeit klappt, ist nicht geklärt. Welches Debian ist denn aus der Generation von Bionic? Ich bin sicher, da lässt sich libgcrypt installieren.

whocares02 schrieb:

Was wäre mit einem Kompile-Vorgang unter Debian?

Na das selbe wie unter jedem anderen System auch: Das ist dann gegen die dortigen Abhängigkeiten in den dortigen Versionen kompiliert.

Welches Debian ist denn aus der Generation von Bionic?

Gar keins.

Das defekte libgcrypt-package aus Bionic bekomme ich aber natürlich so nicht repariert.

Ich glaube nicht, dass libcrypt kaputt ist. Das gehört zur Grundinstallation. da würde dann noch mehr nicht funktionieren.

Ich habe hier übrigens noch einen alten PC mit Bionic gefunden. Da habe ich spaßeshalber mal das -dev Paket installiert. Die angeblich fehlende .pc-Datei ist auch da nicht vorhanden. Von daher glaube ich, du suchst an der falschen Stelle.

Mein Hauptverdächtiger ist daher meson bzw. Python3. Das Buildsystem schafft es irgendwie nicht, die entsprechenden Kommandozeilen für den Compiler zusammenzustellen.

Was wäre mit einem Kompile-Vorgang unter Debian?

Vergiss es. Viele Dateien in den normalen Debian Versionen sind teilweise älter als die von Ubuntu-LTS Versionen. Das liegt daran, dass Ubuntu sich aus dem Testing-Zweig bedient.

Dakuan schrieb:

Ich glaube nicht, dass libcrypt kaputt ist. Das gehört zur Grundinstallation. da würde dann noch mehr nicht funktionieren.

Ich habe hier übrigens noch einen alten PC mit Bionic gefunden. Da habe ich spaßeshalber mal das -dev Paket installiert. Die angeblich fehlende .pc-Datei ist auch da nicht vorhanden. Von daher glaube ich, du suchst an der falschen Stelle.

Die Information, dass libgcrypt in Bionic defekt sei habe ich vom Entwickler des linux-minidisk-forks. Der hat mir auch geschrieben, dass in dem Paket die .pc-Datei fehlt (die in der Kinetic-Version vorhanden ist).

... Der hat mir auch geschrieben, dass in dem Paket die .pc-Datei fehlt ...

Das ist natürlich ein Dickes Ding, besonders da es sich um eine LTS Version handelt.

Allerdings, wenn die fehlende .pc Datei das einzige Problem wäre, müsste es ja jetzt funktionieren. Da klemmt dann wohl noch mehr.