RED C++ QT

[FlyingDoc]

Hat schon mal jemand versucht ein mit QT geschriebenes C++ Programm auf dem RED zum laufen zu bringen?

 

Bei mir schlägt das compilieren schon fehl.

Benutze die QT Bibiliotheken.

[photron]

Was bekommst du denn für Fehler beim compilieren?

[FlyingDoc]

Das er nicht compilieren kann.

 

Hab den RED gestern bekommen und Abends mal schnell probiert.

 

Hatte das HUD Projekt mit dem Brick Viewer rübergeschubst und versucht zu compilieren.

[borg]

Das ist ein bisschen unspezifisch . Welche Fehlermeldung bekommst du denn?

[FlyingDoc]

Executing make False...

...error

[photron]

Das False in "Executing make False" sollte da nicht sein. Du hast da einen Bug gefunden. Der betrifft den C/C++ und Delphi Compile Dialog. Das Kompilieren beim Hochladen ist nicht betroffen. Wird in der nächsten Version gefixt sein.

 

Unter Linux kannst du das bis dahin selbst beheben. In /usr/share/brickv/plugin_system/plugins/red/program_info_c_compile.py Zeile 41 von

 

self.button_make.clicked.connect(self.execute_make)

 

zu

 

self.button_make.clicked.connect(lambda: self.execute_make(None))

 

abändern.

[FlyingDoc]

THX. Werds mal testen. Hab erstma das aktuelle Image draufgenagelt.

[FlyingDoc]

Könnte mir mal jemand bei der Erstellung des make Files unter die Arme greifen?

 

Bin noch kein Linux Spezi und muss mir erst alles mühsam zusammensuchen.

 

Programm ist mit QT in C++ mit den QT Bibiotheken geschrieben mit grafischer Ausgabe.

 

Ein Beispiel würde mir schnell weiterhelfen.

[remotecontrol]

Du musst doch eigentlich nur "qmake" mit dem QT Projektfile aufrufen - oder? (bin kein QT Kenner). Oder wie übersetzt Du das Projekt aktuell?

 

Und im Rahmen vom RED wird beim Upload per Brickv automatisch "make" aufgerufen und Du suchst ein makefile, welches intern den qmake startet?

[FlyingDoc]

Das Make File was QT bei mir auf dem Rechner erstellt sieht etwas anders aus als im Beispiel in der Doku. Es enthält auch die Pfadangaben vom PC.

Vielleicht könnte man dem Brivkviewer beibringen für C das Makefile auf Wunsch auch automatisch mit erzeuegen zu lassen. Er kennt ja die Pfade auf dem RED.

[remotecontrol]

Normalerweise gibt es bei QT doch eine Projektdatei.

Mit qmake und der Projektdatei kann man in einem Buildverzeichnis ein Makefile generieren. Dieses Makefile ist spezifisch (auf jedem Rechner ggf. anders).

 

D.h. ich dachte man müsste auf dem RED auch nur qmake aufrufen und danach make im build-Verzeichnis.

 

Oder ist das bei Dir anders?

 

Ansonsten könntest Du über den Qt-Creator per Rechtsclick auf das Projekt (nicht die pro-Datei) den Befehl "qmake ausführen" aufrufen. In der Console siehst Du, was ausgeführt wird.

 

Mit diesen Befehlen kann ich ein kleines Projekt bei mir bauen:

 

mkdir build_dir
cd build_dir
qmake /absoluter_pfad/zu/qt_test.pro -r -spec linux-g++ CONFIG+=debug
make

 

Sowas schon mal ausprobiert?

[FlyingDoc]

So gerade mal getestet.

 

tf@red-brick:qmake HUD.pro -r -spec linux-g++ CONFIG+=debug

tf@red-brick:~/programs/HUD/bin$ make                                         

/usr/bin/uic-qt4 mainwindow.ui -o ui_mainwindow.h                             

g++ -c -pipe -mno-ms-bitfields -g -Wall -W -D_REENTRANT -DQT_WEBKIT -DQT_GUI_LIB

-DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include

/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -o main.o main.c

pp                                                                             

cc1plus: error: unrecognized command line option ‘-mno-ms-bitfields’           

make: *** [main.o] Error 1                                                     

[remotecontrol]

Du hast qmake im Home-Verzeichnis aufgerufen oder ist das hier nur eine abgekürzte Schreibweise unten?

 

Da Du make im "bin" aufrufst, ist dort ein neues "Makefile" entstanden? Ist der Timestamp aktueller als auf Deinem PC?

 

Der Fehler sieht nämlich danach aus, dass noch das Windows-Makefile aktiv ist oder Du hast fixe Windows-Einstellungen hinterlegt. Die GNU-Compile-Doku sagt zu dem Schalter:

 

Currently -m[no-]ms-bitfields is provided for the Microsoft Windows X86 compilers to match the native Microsoft compiler.

 

=> diese Compile-Option gibt es wohl nur unter Windows.

[FlyingDoc]

So. Hab mal weiter probiert.

Bin jetzt weiter. Er fängt an zu compilieren bricht dann aber ab weil er bestimmte Include Dateien vom QT nicht findet.

 

g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_WEBKIT -DQT_GUI_LIB -DQT_CORE_LIB -DQ

T_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I../bin -I/usr/include/qt4/QtCore -

I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -I../bin -I. -o main.o ../bin

/main.cpp                                                                     

In file included from ../bin/main.cpp:6:0:                                     

../bin/openglwindow.h:41:25: fatal error: QtGui/QWindow: No such file or directo

ry                                                                             

compilation terminated.                                                       

[remotecontrol]

Hier ist noch was mit der Include-Definition schief:

 

der Compiler-Aufruf setzt "-I/usr/include/qt4/QtGui" als Parameter.

Deine Source includier "QtGui/QWindow", d.h. das Unterverzeichnis "QtGui" müsstest Du gar nicht mehr angeben in der Source oder die Include-Option beim Compilieren muss anders sein.

 

Wenn das auf Windows funktioniert ist da noch etwas anders eingestellt oder Du nutzt ggf. eine andere Qt Version (welche nutzt Du eigentlich? 4 oder 5)?

[FlyingDoc]

So. Wieder etwas weiter.

Hab mal die OpenGL Funktionen rauskommentiert.

Nu meckert der Compiler zum Beispiel die Funktion "_mbsnbcmp" und "_strlwr" an.

 

Im Moment die aktuelle QT Version.

Vielleicht müsste man die QT Version auf dem RED aktualisieren.

 

Kann ich das von Hand erledigen?

 

Und noch zwei Hinweise.

Die Console im Viewer sollte scrollbar sein. Sonst sieht man nicht alle Ausgaben.

Und Beim Upload Dialog spollte sich der Viewer den letzen Pfad merken sollange er nicht ausgeschalten wird.

Ist schon extrem nervig wenn man programmiert ,öfters Files ändert und neu hochladen muß.

Man muß sich dann ständig zum Verzeichnis neu durchklickern.

[remotecontrol]

Die beiden Funktionen sind kein Standard-C, sondern Microsoft-Erweiterungen. Die wirst Du ersetzen müssen.

 

strlwr könnte man so umsetzen:

#include<ctype.h>
#include<string.h>

char *strlwr(char *str)
{
  char *s = str;

  while (*s) {
      *s = tolower(*s);
      ++s;
  }

  return str;
}

 

Bei mbsnbcmp musste ich erst nachsehen, was die macht (kannte ich nicht mal): das scheint eine Art strncmp zu sein (String compare mit begrenzter Anzahl Zeichen). strncmp ist Standard-C (denke ich).

 

Nachtrag: strncmp funktioniert mit UTF-8 ggf. nicht korrekt. Verwendest Du das - multibyte Strings?

 

Willkommen bei der Multi-Plattform Entwicklung 

[photron]

FlyingDoc, wenn du Qt verwendest dann bietet es sich an auch das ganze String Handling mit QString zu erschlagen.

[FlyingDoc]

Hmmm. Stimmt. Heute Abend mal umwurschdeln.

 

Gestern stand ich vor einem Abgrund.

Heute bin ich schon einen Schritt weiter!

[FlyingDoc]

Bling. Heute das erste mal zum laufen gebracht. 

[FlyingDoc]

So. Mal das Thema "aufwärmen".

 

Ich versuche gerade auf dem RED die neue Variante mit OpenGL zu compilieren.

 

Es kommt der Fehler.

../bin/GL/gl.h:13:21: fatal error: windows.h: No such file or directory

 

Das betrift folgende Zeile

 

#if !(defined(WINGDIAPI) && defined(APIENTRY))

#include <windows.h>

#else

#include <stddef.h>

#endif

 

Das unter Linux die windows.h nicht existiert ist mir schon klar , weil sie Windows spezifisch ist.

Aber warum versucht der Compiler diese zu laden?

Das ist doch abhängig von dieser Zeile?

#if !(defined(WINGDIAPI) && defined(APIENTRY))

 

Vielleicht kann mir ein Linux C++ Guru auf die Sprünge helfen!

[photron]

Aber warum versucht der Compiler diese zu laden?

Das ist doch abhängig von dieser Zeile?

#if !(defined(WINGDIAPI) && defined(APIENTRY))

 

Ist es. gl.h versucht hier auf komische Art und Weise Windows zu detektieren. Wenn WINGDIAPI nicht definiert aber APIENTRY definiert ist dann will es windows.h includen. Dein Problem hier wird sein, dass irgendwer anders APIENTRY definiert. Das gl.h an diesem doch eher generischen Namen versucht Windows zu erkennen ist problematisch.

 

Paste mal den Anfang der gl.h Datei bis zu der Stelle wo der Fehler auftritt, oder häng die ganze gl.h Datei an einen Post an. Entweder wird vor dieser Stelle ein anderer Header included, der APIENTRY definiert, oder APIENTRY wird im Compiler-Befehl per -D Option definiert. Dass gilt es zu finden und zu beheben.

 

Oder du kannst gl.h hacken und

 

#if !(defined(WINGDIAPI) && defined(APIENTRY))

 

durch

 

#if 0

 

ersetzen und sehen wie weit du dann kommst.

[FlyingDoc]

So gestern Abend mal getestet.

Der gleiche Fehler kommt immer noch obwohl mit deiner Variante oder komplett den Include der windows.h auskommentiert.

[photron]

Naja, der gleiche Fehler kann es ja nicht sein. Denn wenn du den windows.h Include entfernst hast, dann kann dieser ja nicht mehr an der Abwesenheit von windows.h scheitern.

 

Tritt der Fehler jetzt an einer anderen Stelle auf, oder hast du nicht die richtige gl.h Datei editiert?

[FlyingDoc]

So. Nochmal in Ruhe mit deinem Hinweis probiert.

Hatte noch ein Unterverzeichnis mit den GL Dateien drinn.

Hab es mal gelöscht. Dann ging es weiter.

Hatt aber nach ner Weile trotzdem einen Fehler geworfen.

 

Makefile:428: recipe for target 'main.o' failed

make: *** [main.o] Error 1