Prinzipiell :
deine Schnittstelle enthaelt eine klasse, in deinem fall:
DynamicLibrary , deklariert in DynamicLibrary.h
Deiner Applicazion machst die Klasse bekannt durch includen von DynamicLibrary.h
jetzt rufst du an der Klasse irgendwo in der App eine memberfunktion auf.
in deinem fall dyn->greetAudience();
deine App weis das dyn eine klasse vom Typ ist DynamicLibrary iss. weiterhin weis es, das es eine methode greetAudience hat.
was du ihm aber (noch) nicht gesagt hasst, iss dass er greetAudience auch in der dll zu suchen hat ...
Deine Applikation implementiert nirgends DynamicLibrary::greetAudience
In deiner Exportliste deiner DLL steht dfinitiv nur drinn dass die GetClass und GetClassNoParameter zur verfuegung stellt.
Selbst wenn Sie DynamicLibrary::greetAudience zur verfuegung stellen wuerde, wuerde es dir nix helfen.
DU verwendest DynamicLibrary::greetAudience statisch in deinem code. Es muss also beim linken das Symbol DynamicLibrary::greetAudience vorhanden sein.
Aber die DLL wird spaeter dynamisch hinzugeladen.
Das funktioniert also so ned ....
entweder schreibst du dir klassen, die DynamicLibrary::greetAudience an deiner App implementieren und intern zu der dll durchschiessen
machen ueberigens die importlibs, die unter windows gelaufig sind.
Oder du verwendest die methoden ned direkt sondern gleich seperat in ner flachen C-Struktur Ala QString Greetaudience(DynamicLibrary * dyn) in deiner dll und dementsprechend auch exportiert wird.
oder du verpasst DynamicLibrary ne implementation und verlaesst dich drauf das die dll und die app zueinander binaerkompatible versionen der implementierung verwenden ... hasst aber doppelten code. (so wie es in deinem Fall bei QString funktioniert)
weiss ned ob unter linux folgendes funtioniert :
mach nen Interface fuer DynamicLibrary ala IDynamicLibrary.
Code: Alles auswählen
class IDynamicLibrary
{
public:
virtual ~IDynamicLibrary() {}
virtual QString greetAudience() = 0;
};
Uebergib ueber die DLL nur das Interface aber lass deine Dll die klasse irgendwie implementieren.
Hintergrund:
Bei abstrakten methoden wird fuer die Klasse eine vtable generiert. die vtable wird als member der instanz irgendwo relativ zu deinem memberpointer abgelegt. Bei binaerkompatiblen compilern iss die stelle immer gleich. bei VS auch bei debug und release versionen.
Aus vtable wird die anzuspringende Adresse beim aufruf abgefragt, und beim kreiren der instanz mit der ausgepraegten klasse (deshalb kann meine keine abstrakten klassen instanziieren) wurde die ja befuellt, was irgend ein funktionspointer in der dll iss (die hasst ja in der dill erzeugt), der aber ueber den ganzen adressraum gueltig iss, also auch in der App.
Deine app will dann nur noch den prototyp der methode haben (kriegt sie durch das interface) die implementation (den funktionspointer drauf) kriegt sie aber durch die vtable, also mag kein symbol dafuer haben.
Verstanden ?
Funktioniert unter windows super, nutzen wir ziemlich ausgiebig (achtung, man wird kompilerabhaengig, aber das iss man eh schon viel extremer, wenn man QString exportiert) ...
Ciao
error: collect2: ld returned 1 exit status