Hallo,
normalerweise bin ich, um QT Anwendungen auf fremden PCs auszuführen, so vorgegangen:
QMAKE_LFLAGS += -Wl,-rpath,"'\$$ORIGIN'"
und dann kopiert man die shared libs wie zB libQt5Core.so.5.xx.x mit der Verknüpfung libQt5Core.so.5 in den Ordner des Programms.
Mit ldd -v ./anwendung findet man heraus welche files gebraucht werden.
Jetzt habe ich den Fall, dass das OS auf dem Ziel PCs von der Version etwas älter bzw unterschiedlich alt sind so etwa bis debian buster runter. Erstellt wird auf Bullseye. Da ich mit dem Programm alle shared libs mitschleppe dachte ich alles kein Problem aber weit gefehlt.
Fehler beim Öffnen der Anwendung libpcre2-16.so.0 cannot open shared object file: No such file or directory
Aber libpcre2-16.so.0.9.0 und die Verknüpfung libpcre2-16.so.0 sind im Ordner vorhanden. Also sozusagen ein unbegründeter Fehler.
Ab dann kam die Idee statisch zu linken da mich das shared-libs geschleppe eh schon immer nervt und mit den QT Sachen ja sowieso nicht geht (QMAKE_LFLAGS += -static wirft Fehler da keine .a vorhanden). Ok ohne darüber weiter zu meckern wie man so überhaupt ansatzweise Software schreiben will die halbwegs abwärtskompatibel ist eben jetzt der Ansatz nur die QT shared Libs rein zu tun aber dann wenigstens den Rest static.
INCLUDEPATH += /usr/include/c++/9/
LIBS += "/usr/lib/x86_64-linux-gnu/libpcre2-16.a"
rufe ich ldd -v auf wird klar das die Abhängigkeiten weiter von der .so Abhängen also nicht statisch sind.
Das gleiche übrigens mit libstdc++.a und libgcc.a
Auch QMAKE_LFLAGS += -static-libstdc++ -static-libgcc will nicht statisch werden.
Und ja die .a Files existieren wirklich.
Sitze jetzt seit gestern Nachmittag dran, Nacht durchgemacht, gefühlt 1000 stackoverflow Beiträge gelesen und alles mögliche ausprobiert keine Ahnung mehr wie man jetzt da weiterkommt. Auch viele Merkwürdigkeiten bei allem zb mit libboost_system.a wiederum funktioniert der Ansatz mit direkten Verweis auf .a Datei. Und ich habe auch eine Größenänderung der File festgestellt die auf static hinweist, es dann aber eben nicht ist...
Hier wohl ähliches Problem: https://forum.qt.io/topic/46295/com...raries-and-static-gcc-libraries-under-linux/9
Das Endziel ist, dass das Programm möglichst ohne größere Anpassungen auf den Zielrechnern läuft die eben unterschiedliche bzw etwas ältere Versionen haben können. Eine Abwärtskompatibilität von Bullseye bis Stretch würde ja schon reichen.
Meine Ansätze sind alle gescheitert, entweder man löst Problem 1: (libpcre2-16.so.0 cannot open shared object file: No such file or directory) obwohl die Files in echt da sind. Ist wahrscheinlich auch nur die erste File die angezeigt wird, den Fehler würde dann evt auch eine andere File werfen, werden ja einige bei ldd -v angezeigt.
Oder 2: man schafft es libs statisch zu linken während man die QT Dinge dynamisch lässt. Der Versuch wie oben mit direkt auf .a ging nicht oder was falsch gemacht?
Oder 3. Idee, man setzt QMAKE_LFLAGS += -static und definiert die QT Dinge irgendwie als shared damit dann QT keinen Fehler wirft, also der umgekehrte ansatz statt shared als default eben static als default. static als default wäre mir sowieso lieber aber geht das mit QT, kann man die QT shared libs irgendwie in der .pro als shared markieren dass mit -static kein Fehler kommt?
Oder 4. man kompiliert QT selbst so das man alles statisch linken kann, sah aber auf den ersten Blick extrem kompliziert aus... Am Ende stören mich aber die paar Files von QT nicht wirklich, die können auch gerne shared bleiben, der Rest gern static aber selbst wenn dynamisch wäre auch ok, Hauptsache eine Lösung die irgendwie überhaupt funktioniert. Es darf doch nicht sein, dass durch solche Hürden Programme so unglaublich unkompatibel werden.
Gruß
normalerweise bin ich, um QT Anwendungen auf fremden PCs auszuführen, so vorgegangen:
QMAKE_LFLAGS += -Wl,-rpath,"'\$$ORIGIN'"
und dann kopiert man die shared libs wie zB libQt5Core.so.5.xx.x mit der Verknüpfung libQt5Core.so.5 in den Ordner des Programms.
Mit ldd -v ./anwendung findet man heraus welche files gebraucht werden.
Jetzt habe ich den Fall, dass das OS auf dem Ziel PCs von der Version etwas älter bzw unterschiedlich alt sind so etwa bis debian buster runter. Erstellt wird auf Bullseye. Da ich mit dem Programm alle shared libs mitschleppe dachte ich alles kein Problem aber weit gefehlt.
Fehler beim Öffnen der Anwendung libpcre2-16.so.0 cannot open shared object file: No such file or directory
Aber libpcre2-16.so.0.9.0 und die Verknüpfung libpcre2-16.so.0 sind im Ordner vorhanden. Also sozusagen ein unbegründeter Fehler.
Ab dann kam die Idee statisch zu linken da mich das shared-libs geschleppe eh schon immer nervt und mit den QT Sachen ja sowieso nicht geht (QMAKE_LFLAGS += -static wirft Fehler da keine .a vorhanden). Ok ohne darüber weiter zu meckern wie man so überhaupt ansatzweise Software schreiben will die halbwegs abwärtskompatibel ist eben jetzt der Ansatz nur die QT shared Libs rein zu tun aber dann wenigstens den Rest static.
INCLUDEPATH += /usr/include/c++/9/
LIBS += "/usr/lib/x86_64-linux-gnu/libpcre2-16.a"
rufe ich ldd -v auf wird klar das die Abhängigkeiten weiter von der .so Abhängen also nicht statisch sind.
Das gleiche übrigens mit libstdc++.a und libgcc.a
Auch QMAKE_LFLAGS += -static-libstdc++ -static-libgcc will nicht statisch werden.
Und ja die .a Files existieren wirklich.
Sitze jetzt seit gestern Nachmittag dran, Nacht durchgemacht, gefühlt 1000 stackoverflow Beiträge gelesen und alles mögliche ausprobiert keine Ahnung mehr wie man jetzt da weiterkommt. Auch viele Merkwürdigkeiten bei allem zb mit libboost_system.a wiederum funktioniert der Ansatz mit direkten Verweis auf .a Datei. Und ich habe auch eine Größenänderung der File festgestellt die auf static hinweist, es dann aber eben nicht ist...
Hier wohl ähliches Problem: https://forum.qt.io/topic/46295/com...raries-and-static-gcc-libraries-under-linux/9
Das Endziel ist, dass das Programm möglichst ohne größere Anpassungen auf den Zielrechnern läuft die eben unterschiedliche bzw etwas ältere Versionen haben können. Eine Abwärtskompatibilität von Bullseye bis Stretch würde ja schon reichen.
Meine Ansätze sind alle gescheitert, entweder man löst Problem 1: (libpcre2-16.so.0 cannot open shared object file: No such file or directory) obwohl die Files in echt da sind. Ist wahrscheinlich auch nur die erste File die angezeigt wird, den Fehler würde dann evt auch eine andere File werfen, werden ja einige bei ldd -v angezeigt.
Oder 2: man schafft es libs statisch zu linken während man die QT Dinge dynamisch lässt. Der Versuch wie oben mit direkt auf .a ging nicht oder was falsch gemacht?
Oder 3. Idee, man setzt QMAKE_LFLAGS += -static und definiert die QT Dinge irgendwie als shared damit dann QT keinen Fehler wirft, also der umgekehrte ansatz statt shared als default eben static als default. static als default wäre mir sowieso lieber aber geht das mit QT, kann man die QT shared libs irgendwie in der .pro als shared markieren dass mit -static kein Fehler kommt?
Oder 4. man kompiliert QT selbst so das man alles statisch linken kann, sah aber auf den ersten Blick extrem kompliziert aus... Am Ende stören mich aber die paar Files von QT nicht wirklich, die können auch gerne shared bleiben, der Rest gern static aber selbst wenn dynamisch wäre auch ok, Hauptsache eine Lösung die irgendwie überhaupt funktioniert. Es darf doch nicht sein, dass durch solche Hürden Programme so unglaublich unkompatibel werden.
Gruß
Zuletzt bearbeitet:
