Polymorphes QWidget über dll

[RHBaum]

Dann programmier eine, aber verwend sie ned !!!

Und es ist eh alles nen lernprozess

Mir gings genau so. Ich hab auch ne dll programmiert, die fertige tolle QWidgets zur verfuegung gestellt hat.
total easy zu verwenden. Kollegen ham die auch gern verwendet, fuer unterschiedliche projecte. tolle sache eigentlich, und so sollten dlls sein ^^

das ganze ging ne weile gut, bis zu nem bestimmten punkt. dann war diese dll hauptproblemursache bei "Speicherzugriffsverletzung"

Was war passiert ? Alles hat sich weiterentwickelt. auch unsere programme und die qt. aus qt v4.1 wurde v4.2
ok, ich passte die dll an, und kompileierte mit der version 4.2
ploetzlich hatten andere programme das problem. richtig, genau die die noch mit 4.1 liefen. es haben ned alle umgestellt.
Ok kein problem. ich brauch unterschiedliche versionen ...
Ich baute eine version fuer 4.1, 4.2.1 4.2.3 .......
lief auch ne weile gut, die qt version stand ne weile im dll namen ^^
bei 4.3 kam dann plotzlich das service pack 1 fuer VS ....
aus QMyWidgetsImpl_qt4_3_1.dll wurde QMyWidgetsImpl_qt4_3_1_vs5_sp1.dll

Ab dem zeitpunkt war die haeufigste frage .... ja welche dll muss ich nu nehmen ???? ach scheisse, gib mir doch einfach die cpp und den header!

Was war nur aus meiner dll geworden ? ^^

das ist aber auch nen extrem fall .... aber aus sowas lernt man .
Abhaengigkeiten sind sch..... !
binaerabhaengigkeiten, sind die hoechsten, die schlimmsten die es gibt. die machen alle konzepte aufwendig, starr und unflexibel.
GUI's in dlls auslagern ??? nur wenn der leidensdruck gross genug ist. schaff ich es die funktionalitaet auf Schnittstellen ohne GUI runnerzubrechen, wird meine dll um welten flexibler.

dlls, die ich nue austauschen darf, sondern wo ich zur exe immer nur eine bestimmte und passende dll zu bekomme, machen das dll konzept zu nichte ! Am ende nur mehr aufwand.

Das heisst ned das man keine guis in dlls auslagern kann /soll. aber trivial iss das eben nicht ....

Ciao ...

[nuke160]

Ich sehe gerade das ja die Export-Definition fehlt... -> Foren-Suche nach Q_DECL_EXPORTS oder eben ne statische lib benutzen.

Hehe, die Suche findet nur diesen Thread. *gg*
Aber ich habs nachgeschlagen und dort steht dass nur Klassen und Funktionen mit Q_DECL_EXPORTS gekennzeichnet werden müssen, die außerhalb der DLL sichtbar gemacht werden sollen. Dies ist jedoch in diesem Fall nicht gewollt. Nur die Funktionen createNode und releaseNode sollen vom Hauptprojekt sichtbar sein. Und die sind auch so definiert (siehe ein paar Nachrichten weiter oben).

PS: Auch wenn ich Q_DECL_EXPORTS hinzufüge, kommt der gleiche Fehler .

Gruß
nuke160

[nuke160]

@RHBaum : Überredet, ich werd jetzt ne statische Biliothek bauen, mal sehn ob ich das gleiche Problem bekomme , hehe.

Thx
nuke160

[RHBaum]

Wie ist das präzise gemeint? Und: Kann darin die Fehlermeldung begründet liegen?

Nein, der Fehler iss das noch ned, zumindest ned der den oben gepostet hasst. der mit dem qApp kommt aber sicher noch ^^

Die Fehlermeldung sagt dir, du bestimmte methoden von QOBject zwar deklariert, aber ned definiert hasst.
Und es ist definitiv code, was der moccer erzeugt !

das heisst du verwendest irgendwo deine abgeleitete klasse, und zwar ned nur als zeiger, sondern irgendwo voll ausgepraegt. es werden in deiner uebersetzungseiheit die funktionen(die die ueber den moccer generiert werden, stichwort dafuer iss QOBJECT) zu aufgerufen, die implementierung (moc datei in dem falle) aber ned bei der uebersetzungseinheit mit zugelinkt wurde, bzw die implementationsdateien die aus der moc erzeugt werden.

die funktionen aufrufen tust du impliziet, ueber vererbung oder ueber connects (signal slots), unter anderem .....

wo kommt dein linker error eigentlich, bei der dll oder der exe ?
ist dieses project nen qt project ? also linkt auch gegen qtcore und co ???

Ciao ...

[nuke160]

wo kommt dein linker error eigentlich, bei der dll oder der exe ?

Der Error kommt in der dll

ist dieses project nen qt project ? also linkt auch gegen qtcore und co ???

Es ist ein qt projekt und alles Notwendige u.a. qtcore wird auch verlinkt.

[Christian81]

Nur weil ich ein S zu viel habe sucht man nicht in die Richtung weiter? Prima wenn man alles vorgekaut haben möchte...
Es ist Q_DECL_EXPORT nicht Q_DECL_EXPORTS

[nuke160]

Hehe, die Suche findet nur diesen Thread. *gg*
Aber ich habs nachgeschlagen und dort steht dass nur Klassen und Funktionen mit Q_DECL_EXPORTS gekennzeichnet werden müssen, die außerhalb der DLL sichtbar gemacht werden sollen. Dies ist jedoch in diesem Fall nicht gewollt. Nur die Funktionen createNode und releaseNode sollen vom Hauptprojekt sichtbar sein. Und die sind auch so definiert (siehe ein paar Nachrichten weiter oben).

Ja, die Geschichte mit dem S hab ich auch schon herausgefunden, hab aber noch keine Lösung für mein spezifisches Problem entdeckt. Wenn noch bedarf am Kauen besteht, ich wäre froh.


nuke160

[nuke160]

Ich habs jetzt mit ner statischen Bibliothek gemacht und es funktioniert.

Naja, trotzdem vielen Dank für die ganze Hilfe.

cu
nuke160

[solarix]

Nur noch als Ergänzung:

Q_DECL_EXPORT darf nicht direkt eingesetzt werden, sondern da muss eine Zwischenkonstante je nach build (abhängig ob die DLL oder die Applikation generiert wird) auf Q_DECL_EXPORT oder Q_DECL_IMPORT definiert werden. Ausführlich beschrieben wurde das unter
Wie eine Shared Library mit Qt richtig erstellen?

Der falsche Umgang mit diesen Variabeln hingegen führt (nach meiner Erfahrung) nicht zu Linkerfehlern, sondern dass die Anwendung unter Windows ganz einfach nicht startet ("Anwendung kann nicht initialisiert werden" oder so).

Ich vermute daher nach wie vor den Fehler an einer anderen Stelle.

[Christian81]

Die falsche Verwendung führt zu Linkerfehlern... wenn das Symbol ein falsches Prefix bekommt wird es nicht gefunden und es gibt einen Linkerfehler. Beim Start des Programms hingegen hat das Linkerflags nichts mehr zu tun.

[nuke160]

Ich bin mir schon sicher, dass ich Q_DECL_EXPORT richtig verwendet habe, zumal das Erstellen von einer dynamischen Bibliothek mit der Visual Studio Integration automatisch funktioniert.

[Christian81]

Das glaube ich erst wenn ich es sehe...

[solarix]

@Christian: ich kenne die internen Unterschiede von gcc-Version zu gcc-Version nicht, aber
- bei mir, sowie
- hier: http://www.qtforum.de/forum/viewtopic.php?t=3675
- hier: http://www.qtforum.de/forum/viewtopic.php?t=7931 und
- hier: http://www.qtforum.de/forum/viewtopic.php?t=5059
klappte das Linken definitiv, jedoch nicht der Start der Applikation.

@nuke160: möglich.. ich sehe ja nicht auf deinen Rechner... aber "class linNode : public QWidget" ist genauso falsch wie "class Q_DECL_EXPORT linNode : public QWidget"...

[nuke160]

Ok. Hier kommt linnodes_global.h (Automatisch generiert)

Code: Alles auswählen

#ifdef LINNODES_LIB
# define LINNODES_EXPORT Q_DECL_EXPORT
#else
# define LINNODES_EXPORT Q_DECL_IMPORT
#endif

Und hier kommt linnodes.h

Code: Alles auswählen

class LINNODES_EXPORT testNode : public linNode
{
   Q_OBJECT
public:
   testNode(QWidget* parent = 0, Qt::WindowFlags f = 0);
   const bool isInit();
public slots:
   void testslot();
};

Achja, ich möchte noch hinzufügen, dass ich bereits auf eine statische Bibliothek ausgewichen bin. Heisst, ich werde Änderungen wohl nicht mehr ausprobieren können...

[Christian81]

Ich glaube das könnte mit dem fehlenden Q_DECL_IMPORT und dem sogenannten auto-import feature zusammenhängen. Das könnte darauf hinauslaufen dass es zwei verschiedene Symbole zur einer Funktion vorhanden sind oder so. Müsste man genauer untersuchen. Beim MSVC passiert dies definitiv nicht da es dort kein auto-import gibt.