Seite 1 von 1

Probleme mit QScintilla (und -static kompiliertem Qt?)

Verfasst: 20. November 2008 13:55
von nar-12
Hallo.

Ich versuche mich gerade in der Nutzung von QScintilla und bin auf einige Probleme gestoßen.
Das Kompilieren von QScintialla hat problemlos funktioniert.
Wenn ich nun aber ein Objekt vom Typ QsciScintilla anlegen will, bspw.:

Code: Alles auswählen

.h:   
QsciScintilla      *myQsci;  

.cpp:
QsciScintilla = new *myQsci QsciScintilla(splitter);
bekomme ich diverse Fehlermeldungen. Ausserdem meldet QDesigner einen Fehler beim einbinden der dylib von QScintilla, wenn ich dort auf Plugins gehe.
Ich habe Qt 4.4 für mich als -static -release kompiliert. Kann es daran liegen? Und wenn ja, wie kann ich mit einem normalen Qt statische Apps kompilieren, welche keine extra DLLs oder ein installiertes Qt benötigen?

Grüße

Verfasst: 20. November 2008 14:17
von GoaSkin
Du kannst mit einem normalen QT keine statischen Apps erzeugen. Darauf weist Trolltech explizit hin. Der statische QT-Designer ist wiederrum nicht in der Lage, Bibliotheken zu laden.

Tipp: Installiere ein dynamisches QT und compiliere ein statisches QT zusätzlich! Von dem statischen QT brauchst du nur die Kommandozeilentools und die statischen Bibliotheken, die dabei erzeugt werden. Dann kannst du mit dem dynamischen Designer arbeiten, der auch Plugins laden kann.

Du wirst bei diese Lösung zwei qmake-Befehle installiert haben, wobei die Entscheidung, ob das Programm dynamisch oder statisch gebaut wird davon abhängt, welchen QMAKE-Befehl du nutzt.

Ich nutze QT 4.3.5 in beiden Varianten unter OSX. Die dynamische Version liegt in /Library/Frameworks und die statische Version in /usr/local/Trolltech/QT-4.3. Von der statischen Version habe ich nach Ende der Installation den Designer, Linguist, Assistant und die Beispiele wieder entfernt. Die Header habe ich zur Sicherheit gelassen, dürften aber trotzdem mit der dynamischen Variante identisch sein, so daß ggf. ein symbolischer Link auf das andere Verzeichnis reicht.

Zum dynamischen Bau rufe ich 'qmake' auf und zum Statischen '/usr/local/Trolltech/QT-4.3/bin/qmake'. Sowohl g++ als auch xcode funktionieren einwandfrei. Und XCode ruft für das statische Projekt den dynamischen Designer auf, der auch Plugins lädt.

Btw. viele QT-Addons haben Probleme mit QT 4.4. Versuch doch mal downzugraden, wenn du die neuen Features nicht brauchen solltest! Ich nutze eine ältere Version, weil bei QT 4.4 auch die Binärdateien beachtlich größer sind.

Verfasst: 20. November 2008 14:22
von GoaSkin
Übrigens brauchst du solche Addons wie Scintilla garnicht vorzucompilieren. Es reicht aus, das Ding mit der dynamischen QT-Variante zu bauen und das erzeugte Designer-Plugin dort hinzulegen, wo es hingehört.
Den Ordner mit dem QScintilla-Quellcode legst du in einen Unterordner des Projektes. Wenn der uic den Ort eines zu einem Widget gehörenden Frameworks nicht erkennt, setzt er im erzeugten UI-Header eine absolute Inklusion (#include "datei.h"). Beim Compilieren wird diese dann in einem Unterordner des Projektes gesucht, so lange dieser in der Projekt-Datei deklariert ist. Auf diese Weise kann man anderen Leuten auch den Aufwand sparen, QScintilla installieren zu müssen.

Danke für die schnelle Antwort

Verfasst: 20. November 2008 21:46
von nar-12
Hm, ok liest sich erst mal gut.

Zwei Qt Versionen könnte ich mir vorstellen. Wichtig wäre für mich am Ende jedoch ein statisches Kompilat meiner Applikation zu haben, da ich ungern .dll oder sonstiges dazu geben bzw. für mich nutzen möchte. Die src-Nutzer können dies für sich da selbst entscheiden.
Habe übrigens heute mal QScintilla mit einen "cleanen2 Windows Qt 4.4.3, ohne Kompilierung, kompiliert und zu den Desginer Plugins hinzu gefügt - wird wieder nicht erkannt. Ist aber auch nicht so schlimm, da der Desginer von mir nur für kleine Dialoge genutzt wird. Mit Beispielapplikation von QScintilla war dann aber alles ok.

Ich bin der Meinung was von "hinzulinken" von Bibliotheken/libs irgendwo gelesen zu haben. Könnte ich so die QScintilla .dll oder libqscintilla2.5.0.0.dylib und libqscintilla2.dylib (und was da noch erzeugt wurde and dylibs unter Mac OS X) hinzulinken, so das es wieder eine Binärdatei wäre?

Grüße

statisch dazu linken geht nicht

Verfasst: 21. November 2008 08:57
von nar-12
Ich habe es jetzt mal ausprobiert die QScintialla Bibliothek statisch einzubinden und bin grandios gescheitert.
Als Anhaltspunkt habe ich diesen Link verwendet: http://doc.trolltech.com/4.3/plugins-ho ... ic-plugins

Ich bekomme u.a. folgende Fehlermeldung:

Code: Alles auswählen

D:\Qt\qt443\lib" -lmingw32 -lqtmain -lqscintilla2 -lqscintillaplugin -lQtGui
 -lgdi32 -lcomdlg32 -loleaut32 -limm32 -lwinmm -lwinspool -lmsimg32 -lQtCore -lk
ernel32 -luser32 -lshell32 -luuid -lole32 -ladvapi32 -lws2_32
release/main.o(.text+0x249):main.cpp: undefined reference to `qt_plugin_instance_lqscintilla2()'
collect2: ld returned 1 exit status
mingw32-make[1]: *** [release\application.exe] Error 1
mingw32-make[1]: Leaving directory `D:/example-Qt4'
mingw32-make: *** [release] Error 2
Es scheint also etwas mit dem QScintilla Plugin nicht i.O. zu sein.
Die .pro Datei sieht wie folgt aus:

Code: Alles auswählen

CONFIG       += release
HEADERS       = mainwindow.h
SOURCES       = main.cpp \
                mainwindow.cpp
RESOURCES     = application.qrc
LIBS         += -lqscintilla2
QTPLUGIN     += qscintillaplugin
Die von mir erweiterte main von dem Beispiel:

Code: Alles auswählen

#include <QApplication>
#include <QtPlugin>

 Q_IMPORT_PLUGIN(qscintilla2)
 
#include "mainwindow.h"

int main(int argc, char *argv[])
{
    Q_INIT_RESOURCE(application);

    QApplication app(argc, argv);
    MainWindow mainWin;
    mainWin.show();
    return app.exec();
}
Die große Frage ist nun, was mache ich falsch?

Grüße