Dosbox-staging: libpng12 (Ubuntu 16.04 Standard) ist zu alt

Erstellt am 10. Dez. 2019  ·  4Kommentare  ·  Quelle: dosbox-staging/dosbox-staging

Bei der Implementierung von Release-Builds ging ich davon aus, dass libpng12 überall verfügbar sein wird, während libpng16 möglicherweise fehlt … wie sich herausstellt, könnte das Gegenteil der Fall sein.

Es scheint, als ob libpng12 überall verfügbar ist ... außer Ubuntu > 16.04 ... Und einige Pakete könnten ihre eigenen Kopien von libpng12 bündeln, so dass das Paket für einige Benutzer funktioniert und für andere fehlschlägt.

Es scheint, als ob die meisten Distributionen aufgrund von Sicherheitsproblemen standardmäßig auf libpng16 umgestellt wurden.

Ich muss untersuchen, welches Paket von SDL gezogen oder auf den wichtigsten Distributionen standardmäßig vorinstalliert wird, und unsere Skripte und Anweisungen entsprechend anpassen.

bug

Alle 4 Kommentare

Habe gerade die Bestätigung erhalten, dass es sich auch um ein Problem bei der Standardinstallation von Debian Sid handelt. So sind die aktuellen Installationsanweisungen in README.md sind falsch für viele Benutzer.

Toll, dass wir so schnell Feedback bekommen haben; scheitern schnell, wie sie sagen.

Dieses Problem ist Linux- oder vielleicht sogar Ubuntu-spezifisch.

Wir wussten bereits, dass libsdl irgendwie von libpng abhängt… und jetzt wissen wir warum. SDL1.2 hängt von libcaca ab , das wiederum von libpng abhängt. Leider ist diese Abhängigkeit unter Ubuntu 16.04 auf libpng1.2 behoben (SDL1.2-Dev- und libpng1.6-Dev-Pakete können im Ergebnis nicht gleichzeitig installiert werden).

Dies ist eher schlecht, da wir uns nicht um die von libcaca bereitgestellte Funktionalität kümmern, uns aber dadurch zurückgehalten werden. SDL2 hat dieses Problem nicht - es hat die libcaca-Abhängigkeit beseitigt, sodass #29 das Rätsel lösen wird.

Soweit ich das beurteilen kann, haben wir folgende Möglichkeiten:

1) Release-Builds auf Ubuntu 18.04 umstellen - es wäre eine einfache Lösung, aber es werden "bekannte unbekannte" Probleme auftreten: Werden Benutzer von 16.04 LTS und allen Abhängigkeiten (Mint LTS) in der Lage sein, es auszuführen? Ich vermute, dass libstdc++ ein Problem sein könnte, sobald wir dies tun.
2) Nichts tun, bis SDL2 eingebunden ist; SDL2 hat keine solchen Einschränkungen - es ermöglicht auch Builds ohne installiertes libpng. ( aber das ist keine sofortige Lösung ). Außerdem mache ich mir Sorgen um Benutzer von neuem Ubuntus, denen libpng1.2 in Systempaketen möglicherweise fehlt.
3) Deaktivieren Sie die Screenshot-Funktionalität für unsere Linux-Release-Builds; Aktivieren Sie es dann erneut in PR, indem Sie SDL2 einbringen.

@krcroft was meinst du? ich würde mit (3) gehen

Ich bevorzuge auch (3), weil es DOSBox von der direkten Verwendung von libpng und/oder einer bestimmten Version von libpng trennt. Wir hängen immer noch direkt von SDL 1.2 ab, aber das Betriebssystem des Benutzers (wie neu oder alt es auch sein mag) kann alles mitbringen, was zur Erfüllung von SDL 1.2 benötigt wird - sei es libpng 1.2/1.5/1.6, libcacca usw. An.

Eine andere Möglichkeit ist die statische Verlinkung. SDL 1.2 hat seinen Supportzeitraum lange überschritten und ist jetzt eingefroren, so dass moderne Vorteile des dynamischen Linkens (wie das Erhalten neuer Sicherheits-/Bug-/Leistungsbibliotheken) mit SDL 1.2 verloren gehen. (Für SDL 2 ist dynamisches Verknüpfen sehr sinnvoll, da die Community immer noch an Korrekturen arbeitet, während die API-Kompatibilität beibehalten wird).

Mit der statischen Option können wir auch das neueste libPNG und das "beste" SDL 1.2 (mit den Fixes nach 1.2, die Ryan und sein Team in ihrem jetzt viele Jahre alten Quecksilber-Repository enthalten) auswählen, was einige alte Distributionen vielleicht nicht haben abgeholt. Eine statische Binärdatei würde also Benutzern, die nur ältere Systeme verwenden, eine bessere Erfahrung bieten.

Ich denke, der Weg, einen statischen Build zu erstellen, besteht darin, mehr contrib/ Makefiles hinzuzufügen, wie wir es für OpusFile haben. Aber das ist etwas Arbeit und keine sofortige Lösung.

Stimmen Sie also auf jeden Fall (3) zu.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen