Neu erstelltes Qt4 Programm läßt sich nur aus der Konsole starten

R

ralli

Guest
Wenn ich Lyx unter OpenBSD 6.1 installiere, wird ja automatisch das komplette Qt4 installiert. Das ist für mich auch ok, da ich noch einige Projekte habe, die ich später mal auf Qt5 portieren möchte.

Jetzt wollte ich qt4 mal kurz antesten, habe den Path auf
Code: 
export PATH=/usr/local/lib/qt4/bin/:$PATH
gesetzt und habe eine kleine Gui als Probeform erstellt. Das ganze habe ich dann aus dem Terminal mit dem bekannten Dreisatz:
Code: 
$ qmake -project
$ qmake
$ make
compiliert.

Es funktioniert auch und compiliert. Das neu erstellte Programm läßt sich nur aus der Konsole starten mit ./probeform und nicht im Dateimanager Thunar durch einen einfachen Klick, wie ich es früher gewohnt war.
 
ls -lah probeform ergibt:
Code: 
-rwxr-xr-x  1 ralph  wheel  11.9K Aug 24 17:03 probeform
file probeform ergibt:
Code: 
probeform: ELF 64-bit LSB shared object, x86-64, version 1
Für eine Lösung wäre ich dankbar, denn ich möchte ein GUI Programm ja nicht immer aus der Konsole starten oder extra einen Starter dafür erstellen.
 
ralli schrieb:
probeform: ELF 64-bit LSB shared object, x86-64, version 1
Zum Vergrößern anklicken....

Wenn ich ein binary mittels file prüfe, erhalte ich "executable". Wenn ich eine Bibliothek prüfe "shared object":
Code: 
$ file /usr/bin/true
/usr/bin/true: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 10.3, stripped

$ file /usr/lib/libsmb.so.4
/usr/lib/libsmb.so.4: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, stripped

Du machst da vielleicht was falsch.

Rob
 
Hier ein simples C Programm:
Code: 
#include <stdio.h>
int main()
{
    printf ("Flower Power Radio\n");
system("mpg123 http://50.7.129.122:8433/");

    return 0;
}

Das selbe, es läßt sich nicht wie früher mit einem Klick starten, sondern erst mit ./ aus der Konsole.

Es muß in einem sich öffnenden Dialog die gemeinsame Bibliothek angegeben werden, mit dem das Programm gestartet werden soll. Aber da weiß ich nicht weiter, weil ich das noch nie gemacht habe.
 
Das seltsame ist ja, das das Programm von der Arbeitsfläche des Desktop (XFCE) startet, wenn ich einen Starter erstelle. Da weiß ich nicht weiter und das verstehe ich nicht.
 
Hab ich, aber irgendwie liegt hier ein Mißverständnis vor. Wenn es kein Kompilat oder ausführbare Binärdatei wäre, warum läßt es sich dann mit ./probefom starten oder wenn ich einen Starter auf dem Desktop erstelle? Das verstehe ich nicht. Allerdings kommt beim ersten Mal nach der Neuerstellung eines Starters die Abfrage, ob er die ausführbare Datei als vertrauenswürdig markieren soll. Wenn ich das bestätige, startet das comilierte Programm normal, wie es sein sollte.
 
Hast Du mal probiert, die ausführbare Binärdatei in Thunar rechtszuklicken, dann auf den "Permission tab" gehen und den Haken bei "Run as executable file" zu setzen? Das ist wahrscheinlich nur eine Einstellungssache irgendwo oder Thunar sucht in ~/.local/share/applications nach einem launcher oder so.
 
midnight schrieb:
Hast Du mal probiert, die ausführbare Binärdatei in Thunar rechtszuklicken, dann auf den "Permission tab" gehen und den Haken bei "Run as executable file" zu setzen? Das ist wahrscheinlich nur eine Einstellungssache irgendwo oder Thunar sucht in ~/.local/share/applications nach einem launcher oder so.
Zum Vergrößern anklicken....
Ja hab ich, die Option "Datei darf als Programm gestartet werden" im Reiter Zugriffsrechte taucht erst garnicht auf. Wenn ich aber ein Shell Script erstelle, gibt es diese Funktion und ich kann die Datei als ausführbar und vertrauenswürdig aktivieren. Aber wie ich schon schrieb, das ist nicht nur bei einem selbst erstellten Qt Programm so, sondern auch, wenn ich ein C Programm compiliere, wie Beispiel weiter oben. Da ist noch irgendwas anderes oberfaul.
 
Aufgefallen war mir auch, wenn ich qtconfig starte, um zum Beispiel die Schriftgröße für alle Qt4 Programme zu ändern, kann ich das unter Save nicht abspeichern und die Änderungen werden dann natürlich auch nicht übernommen. Das Problem hatte ich auch mal früher bei Debian Stretch, aber das hilft mir hier ja auch nicht weiter. Damals konnte auch niemand das Problem lösen. Hab mal gmake genommen statt make, aber das gleiche .... Das komische ist ja, das es auf dem Desktop funktioniert, wenn ich einen Starter erstelle. Sollte das wirklich aus Sicherheitsgründen so sein? Das ist jetzt nicht weltbewegend schlimm, aber schon ärgerlich.
 
KobRheTilla schrieb:
Was sagt denn file über dein anderes C-Programm?
Und wie genau kompilierst du das?

Rob
Zum Vergrößern anklicken....
Das andere kleine C Programm heißt einfach flower.c und ich comoiliere es so:
Code: 
gcc flower.c -o flower
Na ja, so hat es immer unter FreeBSD 11.1 und früher Linux funktioniert. Für FreeBSD habe ich halt statt gcc den clang Compiler genommen.
 
Und file flower ergibt:
Code: 
flower: ELF 64-bit LSB shared object, x86-64, version 1
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben