Mit Qt 5 compiliertes Programm läßt sich nicht starten

[ralli]

Stimmt @eggy, im rox-filer hab ich es gerade ausprobiert und eingestellt, es funktioniert. Nemo scheint noch einige Bugs zu haben. Wenn ich einen neuen Ordner anlegen möchte, kommt kein Dialog, um den Namen dafür einzugeben, es wird einfach unbekannter Ordner genommen. Den kann ich auch nicht mit F2 oder mit dem Kontext Menu umbenennen. Gut bis Testing stable wird, wird das bestimmt behoben sein. Da muß ich halt ein wenig improvisieren. Der rox-filer war bei meinen Minimalinstallationen eh immer mein bevorzugter Dateimanager.

[ralli]

Nun habe ich geglaubt, wenn Debian Testing den Freeze Status erreicht hat, würde der Fehler behoben sein. Aber ein mit dem Qtcreator compiliertes Programm läßt sich nach wie vor nicht starten. Ein C Programm, was mit GCC compiliert wird ebenfalls nicht. Wenn der Clang eingesetzt wird, läßt sich das fertige Programm starten. Im übrigen tritt dieses Problem nicht nur unter dem Gnome Desktop auf, sondern auch unter dem Mate Desktop, was ich gerade ausprobiert habe. Das ist so vermute ich, daher kein Desktop abhängiges Problem, sondern ein generelles unter Debian Testing. Leider kenne ich mich mit der Fehlerberichtserstattung nicht aus und beherrsche auch kein fließendes Englisch, denn dieser Fehler muß und sollte gemeldet werden. Vielleicht kann das jemand übernehmen, ich finde das wichtig.

[MSfree]

Aber ein mit dem Qtcreator compiliertes Programm läßt sich nach wie vor nicht starten. Ein C Programm, was mit GCC compiliert wird ebenfalls nicht.

In so einem Fall empfiehlt sich das Programm ldd.

Ruft man es mit ldd [NameDesExecutables] auf, wird die Liste der nötigen shared Objects (im Prinzip DLLs) ausgegeben und auch diejenigen, die fehlen. Fehlt etwas, liegt es daran, daß der Runtime-Linker sie nicht in seinem Suchpfad findet. Man kann den Suchpfad für shared Objects in der Umgebungsvariable LD_LIBRARY_PATH ablegen und so den Programmstart ermöglichen.

Permanent kann man den shared Objects Suchpfad in den Dateien unter /etc/ld.so.conf.d machen.

[ralli]

Danke @MSfree, ldd kannte ich schon, mir kommt es merkwürdig vor, das das noch niemanden aufgefallen ist. Gerade unter Linux ist der C oder C++ Compiler unersetzbar. Ich denke, das der Mime Typ x-share/application nicht eingerichtet ist, weiß aber auch nicht, wie man das macht. Oder es fehlt tatsächlich eine Bibliothek, die beim Installieren con GCC, G++ oder clang nicht mitinstalliert wurde. Und bei der unterschiedlichen Anzahl von verschiedenen Compiler Versionen habe ich längst den Überblick verloren.

[MSfree]

Oder es fehlt tatsächlich eine Bibliothek, die beim Installieren con GCC, G++ oder clang nicht mitinstalliert wurde.

Oder, die Bibliothek wurde in einem Verzechnis installiert, in dem der Runtime-Linker nicht per Default sucht. Das ist eigentlich die häufigere Ursache und gerade die Qt5-Libs werden in eigene Verzeichnisse installiert, um sie nicht mit den Qt4, Qt3-Libs durcheinander zu bringen.

Auch, wenn man selber shared Objects kompiliert, sind sie zunächst ja in dem Verzeichnis, in dem die Software kompiliert wird (oder, je nach Makefile, in einem Nachbar-/Unterverzeichnis). Diese findet der Runtime-Linker auch nicht ohne weiteres. Abhilfe shafft hier immer LD_LIBRARY_PATH zu setzen.

[ralli]

Ok, danke, ich werde mir das anschauen und melde mich dann wieder.

Ein kleines Beispiel soll die Problematik verdeutlichen.

Code: Alles auswählen

xdg-mime query filetype flower

Der ermittelte filetyp ist demnach application/x-sharedlib

Jetzt kann ich schauen, welches Programm diesem Mimetyp zugeordnet ist:

Code: Alles auswählen

xdg-mime query default application/x-sharedlib

Ergebnis: nichts

flower ist ein c Programm, was einen Oldiesender mit mpg123 streamt.

[MSfree]

Jetzt kann ich schauen, welches Programm diesem Mimetyp zugeordnet ist:.

Ohne mich jetzt zu sehr aus dem Fenster zu lehnen, aber mit dem Mimetype hat dein Problem meiner Meinung nach nichts zu tun.

Wenn du auf der Kommandozeile den Befehl

Code: Alles auswählen

ldd `which flower`

ausführst und dort shared Objects angezeigt bekommst, die nicht gefunden werden, dann solltest du diese einfach mal auf der Platte suchen. Wenn du das dazu gehörende Verzeichnis gefunden hast, setzt du einefach mit:

Code: Alles auswählen

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:[gefundenes Verzeichnis]

in deinem Termicalfenster und versuchst erneut

Code: Alles auswählen

ldd `which flower`

Solange, bis alle Abhängigkeiten aufgelöst werden können.

Dann kannst du flower von der Kommandozeile starten.

Die Umgebungsvariable LD_LIBRARY_PATH kannst du dann entweder in deiner ~/.profile, /etc/profile oder auch im o.g. ld.so.conf.d verewigen. Erst dann wirst du auch in der Lage sein, dein Programm von der graphiscen Oberfläche zu starten, weil die Umgebungsvariablen nicht systemweit gesetzt werden sondern nur an Kindprozesse vererbt werden.

[ralli]

Nochmals herzlichen Dank für Dein Engagement. Aber ich denke, hier liegt ein Mißverständnis vor. In Beziehung auf das nicht startbare mit Qt5 compilierte Binärprogramm dürfte Deine Aussage wohl zutreffen. Auf das einfache C Programm aber nicht. Mit Clang compiliert, kann ich das Programm auch aus dem Dateimanager (in diesem Falle Caja) starten, mit GCC compiliert nicht. Das das kein GUI Programm ist, weiß ich auch. Das mit Clang compilierte Programm hat den Mime Typ application/x-executable. Ich weiß zwar nicht, wer für das richtige setzen von Pfaden zuständig ist, aber in vergangenen Debian Versionen lief Qt und dem Creator immer alles out of the box. Und diese Unterschiede zwischen den Compilern dürfte eigentlich nicht sein, hatte ich unter anderen Linx Distris und FreeBSD auch nie. Egal, Qt kommt mir nicht mehr auf die Platte, ich habe keine Lust darauf, alles nachzuarbeiten. Werde wohl mit Lazarus weiter arbeiten.

[MSfree]

Mit Clang compiliert, kann ich das Programm auch aus dem Dateimanager (in diesem Falle Caja) starten, mit GCC compiliert nicht.

Auch hier gilt, Clang und GCC verwenden unterschiedliche C/C++-Runtimebibliotheken. Ist eine davon nicht im Suchpfad (LD_LIBRARY_PATH) wirst du es nicht aufruefen können.

aber in vergangenen Debian Versionen lief Qt und dem Creator immer alles out of the box.

Das tut es auch immer noch. Das Problem hier ist aber, daß z.B. bei Jessie noch QT4 der Default ist, QT5 bedeutet hier also immer einen Klimmzug. In Stretch sollte QT5 Default sein, da auch das neuere KDE unter Stretch QT5 voraussetzt.

[ralli]

Auch wenn das so ist, und ich zweifel nicht daran, ist die Vorkonfiguration schlecht, weiter möchte ich mich nicht darüber äußern. Überhaupt wird Qt immer unübersichtlicher. Früher wurde Qt installiert und dann lief das. Heute ist es in dutzende Pakete aufgesplittert. Ob das ein Vorteil ist, wage ich zu bezweifeln. Wenn ich Lazarus installiere, dann läuft und funktioniert es anschließend. Das ist komfortabel. Wenn ich ein neues Auto kaufe, will ich mir auch nicht erst die Zündung einstellen, damit der Motor anspringt. Aber das ist ja auch nur meine persönliche Meinung. Natürlich weiß ich was ein Library Pfad ist, habe den unter anderen Distris (zum Beispiel bei Java) auch schon manuell einstellen müssen. Und wenn ich einen Compiler installiere, muß der funktionieren, egal ob GCC oder Clang. Die augenblickliche Situation erinnert mich an die Anfänge von Linux, da habe ich auch stundenlang mit verbracht, bis der Drucker lief. Irgendwas wird hier von irgendwem vernachlässigt, das finde ich nicht gut.