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

[ralli]

Ich habe Debian Testing mit dem Cinnamon Desktop installiert. Hat auch alles wunderbar funktioniert. Ich habe auch den Qt-Creator installiert und damit eine Anwendung namens Probeweb compiliert und erstellt. Qt ist in der Version 5.7.1 installiert. Die Datei Probeweb ist eine ausführbare Anwendung. Wenn ich Sie im Dateimanager Nemo anklicke,erscheint folgender Dialog:

Unbekannter Dateityp

Der Datei Probeweb sind keine Programme zum Öffnen zugeordnet.

Wenn Sie der Quelle dieser Datei vertrauen und ausreichende Zugriffsrechte haben, können Sie es als ausführbar markieren und starten. Alternativ können Sie über "Öffnen mit" ein Programm zum Öffnen auswählen.

Darunter sind drei Schaltflächen:

Ausführbar machen und starten - das funktioniert, die Anwendung startet dann auch, allerdings nur das eine Mal. Von der Konsole läßt sich das Programm mit ./Probeweb starten.

Programm wählen - bringt nichts, es ist ja eine Binärdatei, die unter X laufen muß

Abbrechen - Ok, das bricht den Dialog ab

Wenn ich die Eigenschaften der Datei aufrufe und anzeigen lasse, steht dort:

Typ: Unbekannt (application/x-sharedlib)

Was muß ich tun, damit ein mit dem QT Creator compiliertes Binärprogramm direkt im Dateimanager Nemo mit einem Klick starten kann.

Wenn ich im übrigen auf dem Cinnamon Desktop einen Starter für das Programm Probeweb anlege, dann funktioniert das auch.

Und natürlich ist das Programm als ausführbar markiert.

[eggy]

Was sagt denn "ls -lah"? Ich könnt mir vorstellen, dass der Datei das "x" fehlt. Siehe Zugriffsrecht "ausführen": http://debiananwenderhandbuch.de/gruppe ... iffsrechte

[ralli]

ls -lah Probeweb ergibt:

Code: Alles auswählen

-rwxr-xr-x 1 ralph ralph 34K Dez 17 06:47 Probeweb

Die Zugriffsrechte hatte ich mir auch schon angeschaut und damit ein wenig mit chmod herumprobiert. Geholfen hat es nicht. Gut es ist kein Malheur, einen Starter zu erstellen, aber normal ist das nicht. Ich habe ja auch Lazarus 1.6 drauf, da funktionieren die ausführbaren und compilierten Dateien. Ob das was mit Testing zu tun hat oder speziell mit Cinnamon 3.x weiß ich auch nicht. Da bin ich im Augenblick etwas überfordert. Vielleicht hat ja jemand noch eine Idee. Aber vorerst ein Mal danke.

[DeletedUserReAsG]

Programm wählen - bringt nichts, es ist ja eine Binärdatei, die unter X laufen muß

Du könntest sh oder bash nehmen.

Magst du mal die Ausgaben von file, ldd und lsattr auf die Datei, sowie die von mount für das FS, in dem sie ist, posten?

[ralli]

Komme erst jetzt wieder an den PC. Nein, das kann ich leider nicht, weil ich Testing bereits von der Platte geputzt habe. Es ist halt Testing und das sagt ja alles. Insgesammt schon ziemlich stabil, aber noch mit Bugs, wie wir ja sehen. Im übrigen hatte ich das selbe Problem auch unter Debian Testing mit dem Mate Desktop. Allerdings wiederum beim Erstellen eines Binärprogrammes mit dem Qt Creator. Natürlich ist das eine Vermutung, die ich jetzt leider nicht beweisen kann. Jedenfalls ist das völlig atypisch. Auch die Nachbearbeitung mit chmod, mit dem ich der Datei Rechte gab, das jeder und alles sie lesen, schreiben und ausführen darf, brachte keine Abhilfe. Trotzdem vielen Dank für Deine Unterstützung @niemand.

[eggy]

Der qtcreator macht auch nichts weiter als qmake aufrufen, was wiederum Makefiles baut, die jenach Einstellung dann gcc oder clang etc aufrufen. Du kannst ja mal das .pro file nach nopaste schieben, daran sollte sich ablesen lassen was qmake macht (template app/lib etc). Aber wenn die Programme mit ./prog auf der Shell funktionieren, liegt der Fehler sicher wo anders, z.B. im Dateimanger. Kann es vielleicht sein, dass Du nachdem Du die Anpassungen in Nemo gemacht hast, das ganze im creator nochmal gestartet (und damit das Binary erstetzt) hast?

[ralli]

@eggy, die Project Datei kann ich leider nicht posten, weil, wie ich bereits im letzten Post schrieb, Testing nicht mehr installiert habe. Und für Nemo hatte ich auch nichts geändert. Ich kann mich nur erinnern, das die Einstellungen im Kit nicht stimmten und sich der Quellcode überhaupt nicht compilieren ließ. Der Creator scheint nicht jeden Compiler zu mögen. Aber auch das ist nicht sicher, sondern auch nur eien Vermutung.

[ralli]

So jetzt hau ich Testing noch mal drauf, so schnell gebe ich nicht auf.

[ralli]

So, nun habe ich Debian Testing neu installiert mit dem Cinnamon Desktop. Für die Qt Entwicklung habe ich folgende Pakete installiert:

build-essential

qtcreator

qt5-default

Dann habe ich mit dem Qtcreator eine Probeform erstellt und compiliert. Das gleiche Ergebnis, das Programm läßt sich von der Konsole starten mit ./Probeform aber nicht wenn ich es anklicke im Dateimanager Nemo. Wenn ich einen Starter auf dem Desktop erstelle, läßt sich das Programm auch beim Anklicken damit starten.

Und hier die angeforderten Daten:

ls -lah in der Konsole ergibt:

Code: Alles auswählen

-rwxr-xr-x 1 ralph ralph 29K Dez 18 07:28 Probeform

file Probeform ergibt:

Code: Alles auswählen

Probeform: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=a29469c017207e3771d3beeb9f243af75bbd5373, not stripped

ldd Probeform ergibt:

Code: Alles auswählen

linux-vdso.so.1 (0x00007fff6dfe4000)
	libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007f258fbb3000)
	libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x00007f258f67a000)
	libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007f258f19b000)
	libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f258ef29000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f258ed0c000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f258e989000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f258e685000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f258e46e000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f258e0d0000)
	libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f258de50000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f258dc36000)
	libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f258da01000)
	libicui18n.so.57 => /usr/lib/x86_64-linux-gnu/libicui18n.so.57 (0x00007f258d587000)
	libicuuc.so.57 => /usr/lib/x86_64-linux-gnu/libicuuc.so.57 (0x00007f258d1df000)
	libpcre16.so.3 => /usr/lib/x86_64-linux-gnu/libpcre16.so.3 (0x00007f258cf76000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f258cd72000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f258ca5e000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f258c854000)
	/lib64/ld-linux-x86-64.so.2 (0x000055948e17e000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f258c62a000)
	libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f258c427000)
	libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007f258c224000)
	libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f258c01d000)
	libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007f258be1a000)
	libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f258bbe9000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f258b9d7000)
	libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f258b7d4000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f258b5ce000)
	libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f258b3cc000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f258b08c000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f258ae62000)
	libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f258ac47000)
	libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f258aa42000)
	libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f258a83c000)
	libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f258a62c000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f258a37b000)
	libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f258a155000)
	libicudata.so.57 => /usr/lib/x86_64-linux-gnu/libicudata.so.57 (0x00007f25886d8000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f2588465000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f2588261000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f2588059000)

lsattr Probeform ergibt:

Code: Alles auswählen

--------------e---- Probeform

mount ergibt:

Code: Alles auswählen

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1016280k,nr_inodes=254070,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=205236k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1423)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=205232k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Allerdings kann ich hier nicht zur Auswertung beitragen.

[DeletedUserReAsG]

Da kann ich kein grundsätzliches Problem entdecken, so dass der Fehler wohl bei Nemo zu suchen ist. Hast du denn mal versucht, eine Shell anzugeben, wenn es dich fragt, womit es die Datei öffnen soll?

[eggy]

Ich habs mal auf sid getestet, Problem ist reproduzierbar. Auch nen minimales C Programm, auf der Shell kompiliert (keine Qt-Libs, kein qtcreator) hat das selbe Problem. Ich würde sagen das ist ein Nemo-Problem, Bugreport gibts bei Debian nach oberflächlicher Suche dazu keinen. Du kannst ja mal schauen, ob bei anderen Distris oder Upstream ( https://github.com/linuxmint/nemo/issues ?) was bekannt ist und ggfs einen Bugreport erstellen.
Magst vorher mal die aktuelle Upstreamversion kompilieren und testen, ob das Problem da auch auftritt?

[ralli]

Ich habs mal auf sid getestet, Problem ist reproduzierbar. Auch nen minimales C Programm, auf der Shell kompiliert (keine Qt-Libs, kein qtcreator) hat das selbe Problem. Ich würde sagen das ist ein Nemo-Problem, Bugreport gibts bei Debian nach oberflächlicher Suche dazu keinen. Du kannst ja mal schauen, ob bei anderen Distris oder Upstream ( https://github.com/linuxmint/nemo/issues ?) was bekannt ist und ggfs einen Bugreport erstellen.
Magst vorher mal die aktuelle Upstreamversion kompilieren und testen, ob das Problem da auch auftritt?

Das kann ich jetzt bestätigen, denn ich habe ein einfaches C Programm compiliert mit demselben Ergebnis.

[ralli]

Da kann ich kein grundsätzliches Problem entdecken, so dass der Fehler wohl bei Nemo zu suchen ist. Hast du denn mal versucht, eine Shell anzugeben, wenn es dich fragt, womit es die Datei öffnen soll?

Bin mir da nicht sicher, denn ich habe das auch unter dem Mate Desktop mit Testing ausprobiert und da trat das gleiche Problem auf.

[ralli]

Ich habe jetzt Mal den rox-filer als Dateimanager installiert. Dasselbe Problem. Wenn ich die ausführbare Qt Programm oder das ausführbare C Programm anklicke, gibt es folgende Fehlermeldung:

Code: Alles auswählen

Es ist keine Startaktion für Dateien dieses Typs (application/x-sharedlib) definiert - Sie können sie setzen, indem sie 'Startaktion setzen' aus dem Dateimenü wählen, oder sie ziehen die Datei einfach auf eine Applikation.

Bin im Augenblick damit überfordert, aber es gilt jetzt als gesichert, das es nicht ein Problem des Nemo ist. Werde mal googeln.

[eggy]

Bei rox-filer (sid) kann man aber übers Kontextmenü "Datei ... "-"Startaktion festlegen" den Punkt "Nur für den Typ 'Gemeinsame Bibliothek' (application/x-sharedlib)" wählen und als Shellbefehl " "$@" " (also das was initial vorgeschlagen wird) festlegen. Im Gegensatz zu Nemo bleibt die Einstellung bei rox-filer erhalten.

[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.