Qt Creator (qt4): Build startet nicht

[LotharS]

Im Nachgang zu einer früheren Frage...

Aber welche Tools = IDEs hätten wir verfügbar? Und welche benutzt Ihr Entwickler wirklich?

habe ich mich mal selbst auf die Suche gemacht und den qtcreator im ANPM entdeckt. Bevor ich aber den in ArcaOS teste, zunächst einmal in meiner Linux-VM deren qtcreator mitsamt qt5(!), gcc, cmake usw. installiert und erste Konsolen-Anwendungen creiert, angefangen von trivialem "Hello World" bis tatsächlich einem komplizierterem Prototyp. Wollte sagen: hat sogar geklappt (wie immer auch im Netz: "was man sucht, findet man als letztes"...).

Nun zurück zu ArcaOS. Der qtcreator dort sucht nach qt4, habe alles zu "qt4" aus ANPM geholt, dazu gcc. Nagut, ein primitives Konsolen-"Hello World" sollte sich doch damit bauen lassen, denke ich. Aber irgendwas scheint hier noch zu fehlen
Beim Ausführen liefert er die Meldungen:

Code: Alles auswählen

Führe Build-Schritte für Projekt hello01 aus...
Starte "c:\usr\bin\qmake.exe" "G:\Projekte\qt\hello01\hello01.pro" -r -spec os2-g++
Der Prozess "c:\usr\bin\qmake.exe" wurde normal beendet.
Der Prozess "make" -w nicht gestartet werden
Fehler beim Erstellen des Projekts hello01(Ziel: Desktop)
Bei der Ausführung von Build-Schritt 'Make'Führe Build-Schritte für Projekt hello01 aus...
Starte "c:\usr\bin\qmake.exe" "G:\Projekte\qt\hello01\hello01.pro" -r -spec os2-g++
Der Prozess "c:\usr\bin\qmake.exe" wurde normal beendet.
[b]Der Prozess "make" -w nicht gestartet werden[/b]
Fehler beim Erstellen des Projekts hello01(Ziel: Desktop)
Bei der Ausführung von Build-Schritt 'Make'

Dazu auf meinen Projekt-"Build-Einstellungen" den Text: "Make-Schritt: make konnte in der Umgebung nicht gefunden werden."
Ein 8k großes Makefile hat er jedenfalls erstellt, nur fehlt anscheinend noch der Kick zum Compilieren

Was mag ich wohl vergessen haben (Installation/Einstellungen)?

Hört sich nebenbei ganz interessant an:

• Den Qt Creator wird es für Qt5 natürlich geben - das ist DIE übliche Entwicklungsumgebung.

[LotharS]

Heute habe ich mich mal "zu Fuß" ins Compile-Getümmel gestürzt.
Hier mein Testprogrämmchen:

Code: Alles auswählen

// #include <QtCore/QCoreApplication>

#include <QTextStream>
#include <QList>
#include <QString>

int main(int argc, char *argv[])
{
    QTextStream out(stdout);
    QTextStream  in(stdin);
    QString eingabe;
    out << "Bitte Text eingeben: " << flush;
    eingabe = in.readLine();
    out << eingabe << endl;
    exit(0);
}

Stammt usprünglich aus dem QtCreator meiner Linux-VM, dort basiert auf Qt5. Funktionierte alles prima. Die o.a. Klassen befinden sich ebenfalls im QtCore von Qt4, sollte eigentlich in ArcaOS damit laufen können. Dachte ich so...
Wie zuletzt geschildert, erzeugte der qtcreator aus ANPM immerhin ein Makefile, wollte aber nicht compilieren. Nun, wenn der Berg nicht zum Propheten kommen will.... :

(1) gcc 9.2.0 war bereits nach dieser bww-Anleitung geholt und installiert.
(2) Folgendes ausgeführt:

Code: Alles auswählen

[G:\projekte\qt\temp]gcc -c -Ic:\usr\include\QtCore  -Ic:\usr\share\qt4\mkspecs\os2-g++  -Ic:\usr\include\c++\9  -Ic:\usr\include\c++\9\bits  -I..\hello01  -o main.obj ..\hello01\main.cpp 

(3) Erster Versuch endete kurz im Fiasko

Code: Alles auswählen

[G:\projekte\qt\temp]gcc -c -Ic:\usr\include\QtCore  -Ic:\usr\share\qt4\mkspecs\os2-g++  -Ic:\usr\include\c++\9  -Ic:\usr\include\c++\9\bits  -I..\hello01  -o main.obj ..\hello01\main.cpp 
In Datei, eingebunden von C:/usr/include/QtCore/qglobal.h:45,
                 von C:/usr/include/QtCore/qnamespace.h:45,
                 von C:/usr/include/QtCore/qobjectdefs.h:45,
                 von C:/usr/include/QtCore/qobject.h:47,
                 von C:/usr/include/QtCore/qiodevice.h:46,
                 von c:\usr\include\QtCore/qtextstream.h:45,
                 von c:\usr\include\QtCore/QTextStream:1,
                 von ..\hello01\main.cpp:3:
C:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/stddef.h:55:10: schwerwiegender Fehler: sys/cdefs.h: No such file or directory
   55 | #include <sys/cdefs.h>
      |          ^~~~~~~~~~~~~
Kompilierung beendet.

(4) Abhilfe mit "yum install libc-devel" schaffte diese erste Hürde, Resultat leider ein Schwall Fehlermeldungen

Code: Alles auswählen

[G:\projekte\qt\temp]gcc -c -Ic:\usr\include\QtCore  -Ic:\usr\share\qt4\mkspecs\os2-g++  -Ic:\usr\include\c++\9  -Ic:\usr\include\c++\9\bits  -I..\hello01  -o main.obj ..\hello01\main.cpp 
In Datei, eingebunden von c:\usr\include\c++\9/locale.h:39,
                 von c:\usr\include\c++\9/clocale:42,
                 von C:/usr/include/c++/9/i686-pc-os2-emx/bits/c++locale.h:41,
                 von c:\usr\include\c++\9/bits/localefwd.h:40,
                 von c:\usr\include\c++\9/string.h:43,
                 von C:/usr/include/QtCore/qbytearray.h:48,
                 von C:/usr/include/QtCore/qstring.h:46,
                 von C:/usr/include/QtCore/qobject.h:48,
                 von C:/usr/include/QtCore/qiodevice.h:46,
                 von c:\usr\include\QtCore/qtextstream.h:45,
                 von c:\usr\include\QtCore/QTextStream:1,
                 von ..\hello01\main.cpp:3:
c:\usr\include\c++\9/bits/locale_classes.h:333:37: Fehler: »_GLIBCXX_NUM_CATEGORIES« wurde in diesem Gültigkeitsbereich nicht definiert
  333 |     enum { _S_categories_size = 6 + _GLIBCXX_NUM_CATEGORIES };
      |                                     ^~~~~~~~~~~~~~~~~~~~~~~
c:\usr\include\c++\9/bits/locale_classes.h: In Konstruktor »std::locale::locale(const string&)«:
c:\usr\include\c++\9/bits/locale_classes.h:163:45: Fehler: falsche Verwendung des unvollständigen Typs »const string« {aka »const class std::__cxx11::basic_string<char>«}
  163 |     locale(const std::string& __s) : locale(__s.c_str()) { }
      |                                             ^~~
In Datei, eingebunden von c:\usr\include\c++\9/string.h:39,
                 von C:/usr/include/QtCore/qbytearray.h:48,
                 von C:/usr/include/QtCore/qstring.h:46,
                 von C:/usr/include/QtCore/qobject.h:48,
                 von C:/usr/include/QtCore/qiodevice.h:46,
                 von c:\usr\include\QtCore/qtextstream.h:45,
                 von c:\usr\include\QtCore/QTextStream:1,
                 von ..\hello01\main.cpp:3:
c:\usr\include\c++\9/bits/stringfwd.h:74:11: Anmerkung: Deklaration von »std::string« {aka »class std::__cxx11::basic_string<char>«}
   74 |     class basic_string;
      |           ^~~~~~~~~~~~
...

plus weitere >4000 Zeilen, die ich uns hier lieber erspare....

Erfahrungsgemäß sitzen die Probleme meines Rechners überwiegendst vor der Tastatur; daher tippe ich auf noch irgendeine kleinen übersehenen Haken.

Bin für jede hilfriche Idee sehr dankbar!

[erdmann]

Installiere mal Paket "kbuild-make". Zusätzlich vielleicht auch noch "kbuild" (vielleicht ist das auch noch nötig).
Ersteres enthält "make.exe" welches offenbar auf deinem System fehlt (sollte in /usr/bin zu finden sein).

[LotharS]

Installiere mal Paket "kbuild-make".

Danke, Lars, das war's -- für den ersten Schritt. Das Compile wurde damit gestartet, aber lieferte erneut eine Flut Fehlemeldungen.
Also weiter einkreisen... (Habe auch noch libc-devel geholt, wozu auch immer...), diesmal so bottom-up wie's nur geht:

(1) Im Qt Creator nochmals alle Einstellungen geprüft: Eigentlich muss man sämtliche Defaults so akzeptieren, denn innen drin scheint alles hart verdrahtet mit original "Qt4" und "g++" zu sein, meinetwegen. Sicherheitshalber alle maßgeblichen Pakete ganz neu installiert...
(2) Im Qt Creator ein neues Konsolen-Projekt = "tutnix" angelegt, lauter Default-Einstellungen, mit "main.cpp" exakt out-of-the-box, tut-weiter-nix:

Code: Alles auswählen

#include <QtCore/QCoreApplication>
int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);
    return a.exec();
}

(3) Resultat: "schwerwiegender Fehler" usw. Ebenso bei einer Variante mit main-body ersetzt durch "exit(0);".
Für einen offline-Compile das erzeugte Makefile "1:1" aufgedröselt:

Code: Alles auswählen

/* REXX */
call directory "G:"
call directory "projekte\qt"
call directory "tutnix-build-desktop"
CXXFLAGS = "-Zomf -march=i486 -mtune=generic -s -O2 -Wall "
DEFINES = "-DQT_NO_DEBUG -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 "
INCPATH = ,
	"-Ic:\usr\include\QtCore ",
	"-Ic:\usr\include ",
	"-I. ",
	"-I..\tutnix ",
	"-I. ",
	"-Ic:\usr\share\qt4\mkspecs\os2-g++ ",
	""
"g++ -c " CXXFLAGS DEFINES INCPATH "-o main.obj ..\tutnix\main.cpp"
exit

Ergebnis (genauso mit gcc statt g++):

Code: Alles auswählen

[G:\projekte\qt\tutnix-build-desktop]g++ -c  -Zomf -march=i486 -mtune=generic -s -O2 -Wall  -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2  -Ic:\usr\include\QtCore  -Ic:\usr\include  -I.  -I..\tutnix  -I.  -Ic:\usr\share\qt4\mkspecs\os2-g++   -o main.obj ..\tutnix\main.cpp 
g++: schwerwiegender Fehler: »as« kann nicht ausgeführt werden: spawnvp: No such file or directory
Kompilierung beendet.

Eine Variante mit in main.cpp zusätzlich "#include <process.h>" brachte nichts anderes.
Suspekt.

[erdmann]

... und nun scheint er den Assembler (as.exe) nicht zu finden.

Also Paket "binutils" installieren. Da ist er nämlich drin. Frag mich nicht warum. Du solltest jetzt anfangen eine Liste zu führen, was du alles installieren musstest ...

[LotharS]

Also Paket "binutils" installieren. Da ist er nämlich drin. Frag mich nicht warum.

Perfekt! Danke!!! Dies war der (vorerst?..) letzte entscheidende Tipp . Noch Kleinigkeiten:
(1) Man muss in den diversen Einstellungen des Qt Creator alles, was nach "Debug" aussieht, abwählen. Sonst meckert er einen fehlenden "QtCored" an, ist mit unserer Qt4-Fassung nicht geliefert. Muss man seine Bugs halt anderswie finden...
Ferner "Ausführen im Terminal" war hier vorher klar.
(2) Sollte beim Build eine Meldung der Art "...runmapsym.cmd not found" erscheinen, einfach den grünen "Ausführen"-Pfeil nochmal drücken und tut. Keine Ahnung warum die Meldung, denn die Datei existiert im angegebenen Pfad.

Doch zurück zum ursprünglichen Projektchen "aus dem Buch":

Code: Alles auswählen

#include <QCoreApplication>
#include <QTextStream>
#include <QString>
#include <iostream>
using namespace std;

int main(int argc, char *argv[])
{
    QTextStream out(stdout);
    QTextStream  in(stdin);

    out << "Bitte Text eingeben: " << flush;
// funktioniert hier nicht wie vorgegeben, aber in Linux:
    // QString qeingabe;
    // qeingabe = in.readLine();
    // out << "Eingegeben war.....: " + qeingabe << endl;
// funktioniert auch hier:
    string ceingabe;
    cin >> ceingabe;
    cout << "Eingegeben war.....: " + ceingabe << endl;
//
    exit(0);
} 

Ich habe gleich auskommentiert was im ArcaOS-Qt4 nicht wie dokumentiert funktionieren will: Die readLine()-Funktion führt darin offenbar zu einem Endlos-Hänger, naja Strg+c .... Alles einwandfrei dagegen in meinem Linux-Analogon (Qt5), und zig Google-Treffer nennen den gleichen Qt-Code. Fragen zur OS/2-Version habe ich indes nicht gefunden, wahrscheinlich weil kaum niemand Probleme nicht mit hat
Kurzum: Es wäre blöd, wenn ich meine kurzen Ausflug ins Qt schon bei den ersten "echten" Funktiönchen abbrechen soll

Du solltest jetzt anfangen eine Liste zu führen, was du alles installieren musstest ...

Ich versuche hier einen Kommentar zu hinterlassen. Nochmals herzlichen Dank für Deine Hilfe!

[LotharS]

Die readLine()-Funktion führt darin offenbar zu einem Endlos-Hänger, naja Strg+c ....

Nach einiger Tüftelei und weiterer Suche im Netz komme ich eher zu folgender Vermutung: Es ist nicht unbedingt die "readLine()"-Funktion, sondern meine quasi Umleitung von stdin auf einen QTextStream bockt in OS/2. Gerade das Qt-mäßige Lesen von stdin scheint nicht trivial zu sein; vielleicht zufällig ähnlich diesem Thread auf os2world oder auch nicht(?). - Macht am Ende nichts, denn auch in Qt darf man ja direkt von "cin" lesen . Oder liefert Qt5 was Neues dazu?

Um diesen "Blog" abzuschließen: Eigentlich ging es mir um ein Prototyp-Projekt von rund 500 Code-Zeilen, welches ich in meiner Linux-VM schließlich erfolgreich vorbereitet hatte und - o Wunder! - mit nur 3 zu ändernden Zeilen auf ArcaOS einwandfrei läuft.
Hinzu kommt, dass sich das in einem früheren Thread behandelte Problem mit Qt IMHO wesentlich eleganter codieren lässt, reines C++. Da hilft, dass Qt umfangreich dokumentiert ist, dazu eine gescheite IDE (Qt5 besser als Qt4), und dass viele Menschen im Netz mit gleichen Fragen kommen wie ich...

Als nächstes möchte ich beginnen, um meinen "fachlichen" Funktions-Prototyp ein graphisches Drumherum zu basteln. Mal sehen, ob's fürs Treffen in Köln was Vorzeigbares wird, verspreche aber nichts....

[LotharS]

Nachtrag:

Hinzu kommt, dass sich das in einem früheren Thread behandelte Problem mit Qt IMHO wesentlich eleganter codieren lässt, reines C++.

Beweis in diesem Sample qt program to execute Linux commands , nur gering angepasst läuft korrekt und flott auf ArcaOS&Qt4.

[LotharS]

Als nächstes möchte ich beginnen, um meinen "fachlichen" Funktions-Prototyp ein graphisches Drumherum zu basteln. Mal sehen, ob's ... was Vorzeigbares wird, verspreche aber nichts....

Für'n Anfang finde ich dieses kleine Exemplar ganz nett. Tut nix, will nur spielen

Im Prinzip ging es mir darum, eine brauchbare Entwicklungsumgebung zu suchen und bin auf den "Qt Creator" gestoßen. Auf ArcaOS ist ja längst die Qt4-Variante erhältlich. Mit Dank an ecsoft2.org und Lars Erdmann:

Code: Alles auswählen

yum install libqt4-gui libqt4 libqt4-webkit libqt4-sql-mysql libqt4-sql-psql qt4-demos qt4-devel-kit qtcreator qtcreator-doc
yum install libc-devel kbuild-make binutils

Nur darf man sich nicht daran stören, dass es aus der *nix-Ecke kommt und es höchstens Wndws-Gui-Anpassungen gibt, aber nicht zu OS/2-PM. Eine etwa zu REXXUTIL analoge Bibliothek out-of-the-box wäre da nicht schlecht (einzelne Funktionen lassen sich aber basteln...). Das kleine Exemplar oben kommt aber mit reinem Qt4 aus und unterscheidet sich von meiner dazu parallelen Linux-Studie (Qt5) an nur wenigen Stellen.

Für die Oberfläche gibt's den integrierten "QT Designer": der produziert endlich wesentlich übersichtlicheren Code als der VAC++ -VisualBuilder und trifft meine Vorstellung von "modularem Design" viel eher. Aber meinetwegen Geschmackssache.

Mein Fazit: Es lohnt, die OS/2-Entwicklung von Qt5 forcieren zu helfen (Qt6 ist schon draußen...). Es ist ja nicht bloß "der Browser", sondern eine recht attraktive komplette Entwickler-Plattform. Am liebsten mit mehr OS/2-Look&feel.