qt5-applikationen starten nach pkg upgrade nicht mehr

Tulkas

Well-Known Member
Hi,
seitdem ich heute die packages geupgradet habe, werfen mir alle QT5 Applikationen folgendes vor die Füße:
Bash:
# qtcreator
/usr/local/lib/qt5/libQt5Widgets.so.5: Undefined symbol "_ZN22QGuiApplicationPrivate11mousePressXE@Qt_5"
# nextcloud
/usr/local/lib/qt5/libQt5DBus.so.5: Undefined symbol "_ZTI14QMetaCallEvent@Qt_5_PRIVATE_API"
# nvim-qt
/usr/local/lib/qt5/libQt5Widgets.so.5: Undefined symbol "_ZN22QGuiApplicationPrivate11mousePressXE@Qt_5"

# pkg which /usr/local/lib/qt5/libQt5Widgets.so.5
/usr/local/lib/qt5/libQt5Widgets.so.5 was installed by package qt5-widgets-5.10.1
# pkg which /usr/local/lib/qt5/libQt5DBus.so.5 
/usr/local/lib/qt5/libQt5DBus.so.5 was installed by package qt5-dbus-5.10.1
# uname -a
FreeBSD freebsd-t450 12.0-CURRENT FreeBSD 12.0-CURRENT #32 r335282: Sun Jun 17 16:36:26 CEST 2018     root@valinor:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64

Es hat fast den Anschein, als ob die qt5-libs und die Applikationen nicht zueinander passen, allerdings nutze ich ausschließlich die offiziellen Pakete. Hat jemand 'ne Idee?

Gruß
 
Ach, das ist ja interessant: Solche Probleme habe ich seit kurzem auf meinem HardenedBSD-Laptop (11-STABLE). Einige qt-Libraries bauen nicht mehr (namentlich mindestens qt5-network). Schau doch mal, ob alle qt-Libraries überhaupt upgedated werden oder ob einige einfach stehenbleiben.

Wir dachten, es läge an HardenedBSD's (Noch-)Verwendung von LibreSSL, da Poudriere beim Kompilieren mit folgender Meldung abbrach:
```
In file included from ssl/qsslsocket_openssl_symbols_p.h:220:
ssl/qsslsocket_openssl11_symbols_p.h:96:22: error: unknown type name 'OPENSSL_STACK'
int q_OPENSSL_sk_num(OPENSSL_STACK *a);
```
Bernard Spil (FreeBSD Port Maintainer sowohl von Open- als auch LibreSSL) war auch erstmal ratlos.

[Edit: Tippfehler]
 
Wir dachten, es läge an HardenedBSD's (Noch-)Verwendung von LibreSSL, da Poudriere beim Kompilieren mit folgender Meldung abbrach:
Switched HardenedBSD von LIbreSSL zurück auf OpenSSL? Wie sieht die Geschichte bei FreeBSD aus? Hier hab ich ausser ein paar alten (2016) Wikiseiten zu LibreSSL nicht viel gesehen...

Welches OS ist das? uname -a und freebsd-version?
 
Switched HardenedBSD von LIbreSSL zurück auf OpenSSL?
Ja. LibreSSL entwickelt sich schnell und diverse Ports passen sich nicht schnell genug an. HadenedBSD hat zuwenig Kapazität um all das selbst zu patchen. Der Switch erfolgt am 1. Juli: https://hardenedbsd.org/article/shawn-webb/2018-04-30/hardenedbsd-switching-back-openssl

Wie sieht die Geschichte bei FreeBSD aus? Hier hab ich ausser ein paar alten (2016) Wikiseiten zu LibreSSL nicht viel gesehen...
Bin ich auch nicht auf dem letzten Stand. Aufgrund der sehr unterschiedlichen Support-Zyklen von FreeBSD und OpenBSD (und damit auch von LibreSSL) gab es mal die Idee, die SSL-Bibliothek im Basis-System "private" zu machen. Dann würde nur das Basissystem selbst daran hängen und könnte vom FreeBSD-Projekt gut in den Griff bekommen werden. Rapide Änderungen in LibreSSL wären somit handhabbar. Wenn Ports eine SSL-Bibliothek nutzen wollen, müsste dann aus den Ports Open- oder LibreSSL in passender Version hinzugefügt werden. Ob das noch Stand der Diskussion ist, weiß ich allerdings nicht.

Welches OS ist das? uname -a und freebsd-version?
Die aktuelle 11-STABLE von HardenedBSD weist sich so aus:
Code:
% uname -a
FreeBSD <servername> 11.2-PRERELEASE-HBSD FreeBSD 11.2-PRERELEASE-HBSD #0 : Thu Jun 14 03:31:14 UTC 2018     root@updater-01:/usr/obj/usr/src/sys/HARDENEDBSD  amd64

% uname -K
1102500

% uname -U
1102500

% freebsd-version
11.2--HBSD
 
Aufgrund der sehr unterschiedlichen Support-Zyklen von FreeBSD und OpenBSD (und damit auch von LibreSSL) gab es mal die Idee, die SSL-Bibliothek im Basis-System "private" zu machen. Dann würde nur das Basissystem selbst daran hängen und könnte vom FreeBSD-Projekt gut in den Griff bekommen werden.
Das wurde auf der BSDCan diskutiert. Das Ergebnis war eher ernüchternd. Ein Prozess kann nur gegen eine SSL-Implementierung linken. Daher müsste nicht nur dass OpenSSL im Basissystem privat sein, sondern auch alle anderen Bibliotheken, die es nutzen. Das ist ein Clusterfuck, der sicher nicht mehr zu 12.0 geklärt wird. Auch wenn LibreSSL theoretisch noch auf der Wunschliste steht. :(
 
Das wurde auf der BSDCan diskutiert. Das Ergebnis war eher ernüchternd. Ein Prozess kann nur gegen eine SSL-Implementierung linken. Daher müsste nicht nur dass OpenSSL im Basissystem privat sein, sondern auch alle anderen Bibliotheken, die es nutzen. Das ist ein Clusterfuck, der sicher nicht mehr zu 12.0 geklärt wird. Auch wenn LibreSSL theoretisch noch auf der Wunschliste steht. :(
@Yamagi: Hast du eventuell einen Link zu den Daten, Präsentation oder Youtube Video oder einen Suchbegriff und dazu mehr zu finden? Ich lande immer wieder im Wiki von FreeBSD und dort steht nur die Info von 2016 und LibreSSL 2.4.1 drin. Danke :)
 
Das war im Rahmen des Dev Summits, ich glaube da wird es keine Videos zu geben. Die Zusammenfassung der 12.0 / 13.0 Planung ist hier: https://wiki.freebsd.org/DevSummit/201806/HaveNeedWant12 Oben auf der Seite sind auch die zugehörigen Bugs verlinkt, in denen die einzelnen Aufgaben verfolgt werden. Wichtig ist im Hinterkopf zu behalten, dass es eine Wunschliste ist und kein Pflichtenheft. Nur weil ein Feature dort steht heißt es nicht, dass es im fertigen Release landet. Das ist u.a. abhängig von der verbleibenden Zeit, dem Interesse und wie invasiv es wäre.

Was da zu FreeBSD 13.0 steht sollte man auch nicht unbedingt für bare Münze nehmen. Das war ein Brainstorming, was sich davon am Ende materialisiert, wird man in einigen Jahren sehen. Einige Dinge davon sind technisch sinnvoll, aber Nutzer schwer zu vermitteln. pf rauszuwerfen zum Beispiel. Andere sind feuchte Träume von Nutzer, aber technisch vielleicht nicht unbedingt zielführend. Unterstützung für die CHERI-Architektur [0] ist so ein Fall. Und wieder andere wahrscheinlich hochumstritten mit Potential für monatelange heftige Diskussionen, wie beispielsweise rc durch OpenRC ersetzen. Man muss also mal schauen wo man sich da am Ende trifft.

0: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
 
Allerdings geht es hier nicht um das Kompilieren, sondern das Ausführen. Ich nutze lediglich Pakete, keine Ports.
 
Ich habe mit einem
Bash:
pkg upgrade -f
und anschließend einiger Wartezeit das Problem beheben können.
 
Zurück
Oben