error LNK2019 bei QFileDialog, sonst wird aber alles gelinkt

Cartman · Beitrag von **Cartman** » 13. April 2007 13:29

Hallo,

ich nutze Qt 4.2.0 (static) und mein Projektfile sieht so aus (Ausschnitt):

TEMPLATE = lib
CONFIG += qt
CONFIG += dll
QT += core gui xml ## ich weiß, core und gui sind default :)

Die Anwendung wird als DLL erstellt, da ich ein Matlab-File (Matlab ist ein Mathe-Tool) bauen will. Matlab lädt es so ein und man kann es dann von dort aus starten. Nun habe ich eine Anwendung mit einem Haufen Dialogen, Buttons, Icons und ListViews, etc. Die Anwendung läuft prima, jedoch gibt es beim Benutzen von Qt-Klassen Warnungen der Art:

Code: Alles auswählen

importdialog.obj : warning LNK4217: Lokal definiertes Symbol "??0QGridLayout@@QAE@XZ (public: __thiscall QGridLayout::QGridLayout(void))" wurde in "public: void __thiscall Ui_ImportDialog::setupUi(class QDialog *)" (?setupUi@Ui_ImportDialog
@@QAEXPAVQDialog@@@Z)-Funktion importiert.

Wie gesagt, es sind nur Warnungen, aber es wird erfolgreich gebaut und gelinkt. Das Resultat funktioniert.

Nun habe ich neuerdings auch QFileDialog in die Applikation miteinbezogen, so daß ich jetzt überraschenderweise nur bei dieser Klasse folgendes bekomme:

Code: Alles auswählen

importdialog.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol
""__declspec(dllimport) public: static class QString __cdecl QFileDialog::getOpe
nFileName(class QWidget *,class QString const &,class QString const &,class QString const &,class QString *,class QFlags<enum QFileDialog::Option>)" (__imp_?get
OpenFileName@QFileDialog@@SA?AVQString@@PAVQWidget@@ABV2@11PAV2@V?$QFlags@W4Option@QFileDialog@@@@@Z)" in Funktion ""private: void __thiscall ImportDialog::on_openButton_clicked(void)" (?on_openButton_clicked@ImportDialog@@AAEXXZ)".
lib\mpi_configure.dll : fatal error LNK1120: 1 nicht aufgelöste externe Verweise

Nun gibt es einen Fehler statt nur einer weiteren Warnung. Hier bin ich nun aufgeschmissen

Weiß jamend, was ich hier falsch mache?

Danke.

Beitrag von **Christian81** » 13. April 2007 16:15

Zu deinen Warnungen - ich kann mir denken was schief läuft , bräuchte aber ein kleines Testcase.
Und zum Fehler - linkst du auch wirklich gegen QtGui ?

Cartman · Beitrag von **Cartman** » 13. April 2007 17:05

Und zum Fehler - linkst du auch wirklich gegen QtGui ?

Sollte die Lib QtGui nicht automatisch durch qmake in die Makefiles plaziert werden? Ich habe noch nie an der Stelle was einstellen müssen...

Wenn ich von dll/lib auf app/exe umstelle, dann bekomme ich keine Warnungen oder Fehler.

Bei der dll nutzt Matlab eine Einsprungfunktion "mexFunction", während ich beim Testlauf als exe die Funktion main implementiere und prinzipell "mexFunction" aufrufe (quasi umleiten). Für die dll habe ich natürlich eine .def-Exportdatei in das qmake-Projekt aufgenommen (DEFFILE = ... oder so), denn sonst findet Matlab die Einsprungstelle nicht.

PS: Ich nutze MSVC2005

der_andreas · Beitrag von **der_andreas** » 13. April 2007 20:12

Cartman hat geschrieben:
Und zum Fehler - linkst du auch wirklich gegen QtGui ?
Sollte die Lib QtGui nicht automatisch durch qmake in die Makefiles plaziert werden? Ich habe noch nie an der Stelle was einstellen müssen...

Wenn ich von dll/lib auf app/exe umstelle, dann bekomme ich keine Warnungen oder Fehler.
[....]
PS: Ich nutze MSVC2005

Bei mir steht der Verweis auf gui und core im .pro file:

Code: Alles auswählen

QT=core gui

Eventuell hast Du da Inkonsistenzen, bzw. Unterschiede drin (Debug/Release, Lib/App).
Nur ne Vermutung...

Cartman · Beitrag von **Cartman** » 13. April 2007 20:25

Natürlich mache ich vorher immer ein "dist clean", d. h. "Rebuild". Sollte also nicht passieren...

Cartman · Beitrag von **Cartman** » 16. April 2007 15:43

Intressant ist vielleicht noch, daß:

* sich Konstruktor und Destruktor von QListWidgetItem erfolgreich linken lassen, ebenso wie die Memberfunktion text(), jedoch ein Linken von setText fehlschlägt (LNK2019)!

* QFileDialog (soweit ich getestet habe) stets nicht linkbar ist (weder C'tor noch D'tor), QDialog aber durchaus linkt (inkl exec-Memberfunktion).

* Andere Klassen wie QPushButton, QIcon, QString, QList, QListWidget, Layouts und vieles mehr (soweit ich die Members getestet habe) erfolgreich linkbar sind.

Wie ich schon erwähnte, verwende ich einen static-Build von Qt4.2.0, den ich an eine dynamische DLL-Lib dranlinken möchte.

Wenn ich auf CONFIG += staticlib umschalte, dann wird ohne Warnungen oder Fehler gebaut, d.h. eine statische *.lib kann ich erfolgreich bauen. Aber eine DLL schlägt fehl (soweit ich die oben genannte Menge an problematischen Klassen/Memberfunktionen in den Code integriere).

Ich weiß hier echt nicht weiter

Beitrag von **Christian81** » 16. April 2007 15:48

Wie schon gesagt - ein kleines Testcase wäre da nicht schlecht. Dein Proggie soweit verkleinern bis entweder der Fehler nicht mehr auftritt oder eben bis es als Testcase klein genug ist.

Cartman · Beitrag von **Cartman** » 16. April 2007 17:31

So, ich habe mal einen "Testcase" erstellt. Das Programm ist nun extrem minimal, sogar MATLAB-Spezifika sind nun entfernt.

Das Programm linkt erfolgreich in der Form, wie es im Zip-Anhang enthalten ist. Es kommen nur Warnungen LNK4217.

Kommentiert man allerdings die markierte Zeile im Code, dann kracht es mit Fehlern LNK2019 wie folgt:

Code: Alles auswählen

.\main.cpp(11) : warning C4100: 'dummy': Unreferenzierter formaler Parameter
        link /LIBPATH:"c:\Programme\Qt\4.2.0-win32-msvc2005-static\lib" /NOLOGO
/INCREMENTAL:NO /INCREMENTAL:NO /DLL /OUT:release\testcase.dll @c:\DOKUME~1\pgraebel\LOKALE~1\Temp\nm1F7.tmp
main.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: virtual __thiscall QApplication::~QApplication(void)" (__imp_??1QApplication@@UAE@XZ)" in Funktion "_mexFunction".
main.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: virtual __thiscall QDialog::~QDialog(void)" (__imp_??1QDialog@@UAE@XZ)" in Funktion "_mexFunction".
main.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: int __thiscall QDialog::exec(void)" (__imp_?exec@QDialog
@@QAEHXZ)" in Funktion "_mexFunction".
main.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: __thiscall QDialog::QDialog(class QWidget *,class QFlags<enum Qt::WindowType>)" (__imp_??0QDialog@@QAE@PAVQWidget@@V?$QFlags@W4WindowTyp
e@Qt@@@@@Z)" in Funktion "_mexFunction".
main.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: __thiscall QApplication::QApplication(int &,char * *,int)" (__imp_??0QApplication@@QAE@AAHPAPADH@Z)" in Funktion "_mexFunction".
release\testcase.dll : fatal error LNK1120: 5 nicht aufgelöste externe Verweise.

NMAKE : fatal error U1077: ""c:\Programme\Microsoft Visual Studio 8\VC\bin\link.
EXE"": Rückgabe-Code "0x460"
Stop.
NMAKE : fatal error U1077: ""c:\Programme\Microsoft Visual Studio 8\VC\bin\nmake
.exe"": Rückgabe-Code "0x2"
Stop.

Wie gesagt, static Qt 4.2.0 wurde hier mit MSVC2005 verwendet. Wem das extern "C" stört: Die Fehler kommen auch ohne! Die Anweisung ist nötig, da MATLAB in der DLL eine C-Schnittstelle erwartet.

Prinzipiell muß man das beiliegende DEF-File noch miteinbinden, aber ist hier im Testfall offenbar unerheblich. Daher ist das DEF-File im qmake-File erstmal wegkommentiert.

Beitrag von **Christian81** » 16. April 2007 17:37

Danke,

mit einer dynamische qt-Version (atm 4.3.0beta)sieht es ok aus - werde morgen mal mit der statischen Version testen (4.2.2).

Cartman · Beitrag von **Cartman** » 16. April 2007 17:41

Danke, ich erwarte gespannt dein Ergebnis

Beitrag von **Christian81** » 17. April 2007 10:40

So, habe den Fehler gefunden. So wie es aussieht hat qmake da ein kleines Problem. Das Define '-DQT_DLL' muss entfernt werden damit es funktioniert.
Ausserdem würde ich Qt noch etwas modifizieren damit Du auch unabhängig von den MSVC-runtimes bist -> http://qtnode.net/wiki/Qt4_with_Visual_ ... _C_runtime

Cartman · Beitrag von **Cartman** » 17. April 2007 12:46

Herzlichen Dank

Neben dem reduzierten Testprogramm läuft nun auch das Originalprogramm mit all seinen angewandten Qt-Features.

Ein DEFINES -= QT_DLL für das qmake-File beseitigt das Define allerdings nicht. Also habe ich in die Header-Dateien ein entsprechendes #undef eingefügt. So geht es. Ich vermute aber, daß man mit den QMAKE_*-Variablen das Define auf elegantere Art beseitigen kann...

PS: Wie kann man die Endung (Suffix) der erstellten DLL von .dll auf .xyz per qmake-Datei umstellen? MATLAB erwartet vorzugsweise DLLs mit einer eigenen Endung, auch wenn das (zumindest bis zu aktuellen Version) nur optional ist...