QT 4.5 unter Linux - Library wohin packen?

[ms47]

Hallo,

habe Qt 4.5 mit dem Qt Creator unter Linux installiert. Das ganze wurde im Verzeichnis /opt/qtsdk-2009.01 installiert.
Das kompilieren und ausführen eines Programms funktioniert auch soweit, allerdings wenn ich das Programm weitergeben möchte, habe ich ja nur die Binary-Datei. Führe ich die Datei dann ohne installiertes SDK aus, so kommt folgende Fehlermeldung:

Code: Alles auswählen

./main: symbol lookup error: ./main: undefined symbol: _Z13qFlagLocationPKc

Klar, denn er findet ja auch die Librarys nicht. Aber auch wenn ich alle Libs in das Programmverzeichnis kopiere, findet der die nicht.
Ich hätte das gern so, dass die Libs dann im Programmverzeichnis sind und auch von dort genommen werden. Und ich möchte nicht statisch linken.
Hat jemand eine Idee, wie ich das anstelle?
Danke schon mal.

Gruß
Markus

[Strahlex]

Welche Distribution verwendest du?
Jede größere Distribution sollte bereits binäre Qt 4.5 Pakete in den Repositories anbieten.

EDIT: ob das mit dem statisch linken unter Linux geht weis ich nicht, entfällt meistens aus oben genannten Gründen sowieso, ich denke es gibt mittlerweile keine Distri ohne vorinstalliertem Qt 4 mehr

[ms47]

Welche Distribution verwendest du?
Jede größere Distribution sollte bereits binäre Qt 4.5 Pakete in den Repositories anbieten.

EDIT: ob das mit dem statisch linken unter Linux geht weis ich nicht, entfällt meistens aus oben genannten Gründen sowieso, ich denke es gibt mittlerweile keine Distri ohne vorinstalliertem Qt 4 mehr

Hi, danke für die schnelle Antwort.
Ich verwende Kubuntu 8.10. Aber in den Quellen habe ich die noch nicht gefunden. Dort habe ich nur die 4.4.3er Versionen drin.

[RavenIV]

Welche Distribution verwendest du?
Jede größere Distribution sollte bereits binäre Qt 4.5 Pakete in den Repositories anbieten.

Das wird noch einige Zeit dauern, bis Qt 4.5 in den Distributionen auftauchen.
Bis dahin sollte man entweder so programmieren, dass die eine oder andere Version von Qt verwendet werden kann.
Oder man beschränkt sich darauf, dass nur Qt 4 benutzt wird.

[Undefined]

Hallo,

habe Qt 4.5 mit dem Qt Creator unter Linux installiert. Das ganze wurde im Verzeichnis /opt/qtsdk-2009.01 installiert.
Das kompilieren und ausführen eines Programms funktioniert auch soweit, allerdings wenn ich das Programm weitergeben möchte, habe ich ja nur die Binary-Datei. Führe ich die Datei dann ohne installiertes SDK aus, so kommt folgende Fehlermeldung:

Code: Alles auswählen

./main: symbol lookup error: ./main: undefined symbol: _Z13qFlagLocationPKc

Klar, denn er findet ja auch die Librarys nicht. Aber auch wenn ich alle Libs in das Programmverzeichnis kopiere, findet der die nicht.
Ich hätte das gern so, dass die Libs dann im Programmverzeichnis sind und auch von dort genommen werden. Und ich möchte nicht statisch linken.
Hat jemand eine Idee, wie ich das anstelle?
Danke schon mal.

Gruß
Markus

Siehe die Manpage von ld und das Thema LD_LIBRARY_PATH und schreibe dir ein Startscript.

[FaS]

Wenn du die libs (und nicht die symlinks auf die libs!, also z.B. libQtCore.so.4.5.0) in das Verzeichnis packst, in welchem die Anwendung liegt, sollte das funktionieren. Zumindest tut es das bei mir unter Debian.

Bei Qt-Plugins ist das was anderes. Die werden dynamisch geladen aber überhaupt garnicht erst im Anwendungsverzeichnis gesucht, da hilft ein

Code: Alles auswählen

  QCoreApplication::addLibraryPath( "." );

in der main (weiß grad nicht ob eine relative Angabe reicht, denke mal schon).

Und der Vollständigkeit halber: Für die Übersetzung (sonst sind Qt-Texte auf Nicht-Qt-Systemen englisch): Sprachdatei qt_de kopieren und:

Code: Alles auswählen

  QTranslator translator;
  translator.load( "qt_de" );
  app.installTranslator( &translator );

Gruß,
FaS

[The User]

Also in meinen Repos ist seit Wochen schon Qt4.5. Mag bei den Debians vielleicht anders sein.

[ms47]

Wenn du die libs (und nicht die symlinks auf die libs!, also z.B. libQtCore.so.4.5.0) in das Verzeichnis packst, in welchem die Anwendung liegt, sollte das funktionieren. Zumindest tut es das bei mir unter Debian.

Bei Qt-Plugins ist das was anderes. Die werden dynamisch geladen aber überhaupt garnicht erst im Anwendungsverzeichnis gesucht, da hilft ein

Code: Alles auswählen

  QCoreApplication::addLibraryPath( "." );

in der main (weiß grad nicht ob eine relative Angabe reicht, denke mal schon).

Und der Vollständigkeit halber: Für die Übersetzung (sonst sind Qt-Texte auf Nicht-Qt-Systemen englisch): Sprachdatei qt_de kopieren und:

Code: Alles auswählen

  QTranslator translator;
  translator.load( "qt_de" );
  app.installTranslator( &translator );

Gruß,
FaS

Guter Tipp, danke dir für die ausführliche Antwort.

Also in meinen Repos ist seit Wochen schon Qt4.5. Mag bei den Debians vielleicht anders sein.

Welche Distribution verwendest du genau?

[RHBaum]

Aber es ist ned sinn von so's und dem packetmanagment unter Linux, das man zum program seine eigenen qt libs installiert.
Langt schon, wenn man unter Windows so Kruecken bauen muss.

der Linux Optimale weg waere:
Fuer sein programm ein Packet (je nach distri rpm, deb oder was weiss ich) bauen, wo die Abhaengigkeiten beschreiben sind.
Auf nen System ohne die qt libs wuerde das dann entweder die qtlibs mit zur Installation aus den öffentlichen Quellen anbieten, oder die Installation gar ned machen wollen.

Viele momentane Distries werden bei qt4.5 zwar noch rumzicken, und es nicht standardmaessig installieren lassen, sondern das einbinden von Fremdquellen verlangen, mit allen warnungen ueber stabilitaet etc. Was aber auch gerechtfertigt ist, weil Momentan isdt die verwendung der qt4.5 unter linux auch ned wirklich getestet.

Alternativ kannst ja son packet fuer die qt4.5 parrallel selbst anbieten fuer deine bevorzugte distri ....

Ubrigens ist die qt4.5 runtime bei Ubuntu ab Jaunty (momentan alpha) dabei. Gibt sicher irgendwo schon nen Repo wo man sich sein 8.10er Intrepid Ibex mit beschmutzen kann Notfalls gehen alle debian packages und repositories.

Ciao ...

[Godless]

Kann sein, dass ich dein Problem falsch verstehe, aber normalerweise gehören die libs nach /usr/lib. Einen spezifischen Anwendungsordner gibt es nämlich unter Linux nicht, /usr/bin für die ausführbaren Dateien, /usr/lib für die Bibliotheken, /usr/share für Daten etc.

[FaS]

Dann würden manche Programme aber die neuen Qt-Libs heranziehen, oder?, was aufgrund von "ungenügend geteset" usw. wohl nicht unbedingt von jedem User so gewünscht wird. Und diese später zu deinstallieren wird mit gewissen Paketmanagern wohl auch nicht so einfach möglich sein.
Meiner Meinung nach hat Linux einen Designfehler bezüglich der Verwaltung, besonders der Kategorisierung von Bibliotheken, und warum sollte man sich dann damit rumschlagen, wenn man einfach alle Dateien im Programmordner lagern kann. So weiß man wenigstens immer ganz genau, dass der Benutzer die aktuelleste Version besitzt, mit genau den Bibliotheken, die auch wirklich dazu passen. Schließlich weiß der Programmierer besser als der Benutzer, was für sein Programm am besten ist. Und wenn man parallel Windowsversionen veröffentlichen möchte, macht es erst recht kaum Sinn für Linux son Aufwand zu betreiben, welcher im Endeffekt eh nur Probleme bereitet. Man sollte (rhetorischer Imperativ) akzeptieren, dass das Konzept nicht perfekt ist, und es sich nicht selbst mit ganzer Kraft blind schönreden. Auch wenn es im Vergleich zu Windows schon ganz toll ist.
Andererseits find ich die vorgeschlagene Lösung doch äußerst hässlich. Aber für Benutzerendanwendungen, also die am Ende der Nahrungskette, mag das wohl reichen.

[RavenIV]

Kann sein, dass ich dein Problem falsch verstehe, aber normalerweise gehören die libs nach /usr/lib. Einen spezifischen Anwendungsordner gibt es nämlich unter Linux nicht, /usr/bin für die ausführbaren Dateien, /usr/lib für die Bibliotheken, /usr/share für Daten etc.

Es hindert mich aber niemand daran, in /usr/lib einen Ordner Qt4 und Qt4.5 anzulegen und diese im path bekannt zu machen.
Dann kann sich die Software aussuchen, welche Qt-Version sie benutzt.

[RavenIV]

Meiner Meinung nach hat Linux einen Designfehler bezüglich der Verwaltung, besonders der Kategorisierung von Bibliotheken, und warum sollte man sich dann damit rumschlagen, wenn man einfach alle Dateien im Programmordner lagern kann. So weiß man wenigstens immer ganz genau, dass der Benutzer die aktuelleste Version besitzt, mit genau den Bibliotheken, die auch wirklich dazu passen. Schließlich weiß der Programmierer besser als der Benutzer, was für sein Programm am besten ist.

Ja genau
So ein Quatsch. Dann kopiert jedes Programm jene Libs ins sein Verzeichnis, die es für nötig hält. Und somit ist das ganze System mit hunderten von Libs zugemüllt, von denen 95 % überall die gleichen sind.
Was ist an der Bibliotheksverwaltung bei Lunix schlechter als anderstwo?

[RHBaum]

Meiner Meinung nach hat Linux einen Designfehler bezüglich der Verwaltung

Nein, wenn der Fehler wo steckt, dann ned in der Verwaltung.
Wenn sich alle Programmierer, sowol die die der libs als auch die der Progs an konventionen halten, sollte nix schief gehen.

Ich kann in meinem Prog z.b. die qt version erzwingen. ich kann expliziet z.b. die qt 4.2.3 anziehen. Das schlimmste was passieren kann, ist das ich auf ein system komme, wo diese version nicht angeboten wird in den repos. Mein package wuerde sich nicht installieren lassen.

ueblicher ist, das man nur die major version angibt, also qt4 z.b. und das das LD system dann dynamisch die neusten libs zulinkt.
Da alle bibs abwaerts kompatibel sein muessen innerhalb der gleichen major version, sollte es dem author des programms wurscht sein, ob es genau seine oder ne neuere version der qt vorfindet.
Schlimmer ist der fall andersrum, wie hier der Fall ist ... er findet in der selbem major eine fruehere version ....
Da kann das LD system ned helfen, dafuer greift das packet managment ! dort kann man bei den abhaengigkeiten mindestversionen angeben ...

noch viel ueblicher ist eigentlich, sein prog als source code auszulieferen ... da gibts noch weniger probs.
die mindestversionen der bibs werden mittels der config.h (./configure) abgefangen, und wenn nicht vorhanden, wird das binary ned erstellt.

Die Ursache hier ist also nicht die fehlerhafte Verfaltung bei Linux, sondern die ungeduld des Authors des Programms (qt4.5 ist bei den meisten distries noch lange ned im stable), gepaart mit ... Ignoranz gegenueber den unter linux uebelichen verbreitungsmethoden von software, die eben genau solche versionsabhaengigkeiten abfangen sollen !
mal eben nen binary weitergeben iss ned ! entweder package, oder src code packet !!! nur so wird die Integritaet des linux systems gewahrt.

ciao ...

[FaS]

So ein Quatsch. Dann kopiert jedes Programm jene Libs ins sein Verzeichnis, die es für nötig hält. Und somit ist das ganze System mit hunderten von Libs zugemüllt, von denen 95 % überall die gleichen sind.
Was ist an der Bibliotheksverwaltung bei Lunix schlechter als anderstwo?

Das ist bloß die Notlösung... Und ich hab nicht gesagt, dass es etwas besseres gibt, nur, dass das aktuell nicht optimal ist. Die Idee, alle Komponenten zu trennen und Redundanz zu vermeiden, ist gut, jedoch darf es doch nicht zu Kollisionen kommen, nur weil ein Programm Qt 4.5 braucht. Die Kategorisierung gleicher Bibliotheken/Programme unterschiedlicher Version fehlt einfach, vielleicht ist das ja schon alles.

Nein, wenn der Fehler wo steckt, dann ned in der Verwaltung.
Wenn sich alle Programmierer, sowol die die der libs als auch die der Progs an konventionen halten, sollte nix schief gehen.

Doch!:

Viele momentane Distries werden bei qt4.5 zwar noch rumzicken, und es nicht standardmaessig installieren lassen, sondern das einbinden von Fremdquellen verlangen, mit allen warnungen ueber stabilitaet etc.

Das ist ein Hindernis, oder nicht (also nicht die Warnungen, die kann man ja akzeptieren)? Hindernis = Designfehler! Was gibt's da zu diskutieren. Wenn der Mensch im Endeffekt das Problem lösen kann, dann kann das auch eine Maschine. Und diese "Quellen", das sind ja wohl auch nicht gerade saubere/übersichtliche Filterlösungen, v.a. da sie irgendwie recht global greifen. Und das alles fällt unter den Begriff "Verwaltung". Warum benutzen wohl so wenige Linux? Weil man sich da tagelang mit solchem Kram beschäftigen muss, welcher im Grunde vollkommen überflüssig sein könnte.