DLL die von DLL abhängen :-)

Hallo.
Mein Projekt entwickele ich vor allem für Linux. Dazu habe ich eine Hierachie von shared libraries. "core" und einige darauf aufbauende. Kompiliert wird das dort ungefähr so:

g++ -shared -fPIC core.cpp -o libcore.so

Das funktioniert auch wunderbar mit den Erweiterungen, welche zumeist aus abgeleiteten Klassen des "core" Teils sind.

In Windows kann ich (sofern ich fPIC weglasse - warum eigendlich?) "core" auch ohne weiteres bauen. Jedoch streikt gcc bei den aufbauenden libs a la:

extension.cpp:554: undefined reference to `coreTag_t::~coreTag_t()'

Bin ich gezwungen in Windows alles in eine große DLL zu packen oder wie soll ich das verstehen?!

Danke euch ...

Troll wo anders!

na und schrieb:

Troll wo anders!

Gibts vielleicht irgendwas verachtenswertes an der Frage von dem ich nichts weiss??!

nö. einfach ignorieren und abwarten, es kommt bestimmt noch einer vorbei der bescheid weiß.

drakon

geduld, junger padawan schrieb:

...

Was habt ihr alle in letzter Zeit so von Starwars?! - Macht Pro7 etwa wiedermal extrem nervige Werbung für die Filme?!

@Problem:
Der Fehler sagt nur, dass er eine Definition nicht finden kann. Du hast auch sicher nichts verändert?

drakon schrieb:

@Problem:
Der Fehler sagt nur, dass er eine Definition nicht finden kann. Du hast auch sicher nichts verändert?

Naja er kann es nicht finden weil es sich in einer anderen library befindet! Aber in Linux ist das kein Problem. Da braucht nur das Hauptprogramm alle Abhängigkeiten der jeweiligen lib.

drakon schrieb:

Was habt ihr alle in letzter Zeit so von Starwars?!

entweder ist es zufall, oder die dunkle seite der macht zwingt uns dazu.

Macht Pro7 etwa wiedermal extrem nervige Werbung für die Filme?!

welcher vernunftbegabte mensch schaut sich denn bitte pro7 an? oder werbung??

Fellhuhn

Mal sehen... Force Unleashed, Pro7, neues Star Wars MMO... Clone Wars... Gibt schon genug Nerd-Futter.

Ungeachtet dieser Star Wars Weisheiten wird doch auch jemand was zum Topic zum dazusenfen haben oder?

case

Sind deinen Klassen auch richtig exportiert ?
Stichwort: __declspec(dllexport) beim export und __declspec(dllimport) beim import

case schrieb:

Sind deinen Klassen auch richtig exportiert ?
Stichwort: __declspec(dllexport) beim export und __declspec(dllimport) beim import

Nein ... das ist was Windows spezifisches?!
Ich mach mal ein konkretes Beispiel:

#ifndef CORE_H
#define CORE_H

class core
{
   virtual void member();
};

#endif

//core.cpp
#include "core.h"
/*ganz toller code*/

#ifndef EXT_H
#define EXT_H

#include "core.h"

class ext : public core
{
};

#endif

#include "ext.h"
/*weitere genialitäten*/

So ... core.cpp ist meine shared library. ext.cpp nutzt die auf die ein oder andere weise ( hier halt abgeleitet ). ext soll auch eine eigenständige library sein.

Mit Linux und gcc compiliere ich das einfach so:

g++ core.cpp -shared -fPIC -o libcore.so
g++ ext.cpp -shared -fPIC -o libext.so //HIER DER FEHLER "undefined reference" in windows!!

Beim bauen von ext sind die definitionen ja auch ned bakannt!!!! Unter windows funktioniert das so nicht. Zum reinen compilieren von libext.so brauche ich ja libcore.so nicht mal!!!

Mein Hauptprogramm wird dann eben so gebaut:

g++ programm.cpp -o prog -lcore -lext

Eigendlich ganz simpel

schieb

sothis_

case schrieb:

Sind deinen Klassen auch richtig exportiert ?
Stichwort: __declspec(dllexport) beim export und __declspec(dllimport) beim import

sothis_ schrieb:

case schrieb:

Sind deinen Klassen auch richtig exportiert ?
Stichwort: __declspec(dllexport) beim export und __declspec(dllimport) beim import

Okay, 2x für Dummies

Aaalso: So sieht nun mein classA.h aus:

#ifndef CLASSA_H
#define CLASSA_H

#ifdef WIN32
#ifdef EXPORT
    #define CLASS_DLSPEC __declspec(dllexport)
#else
    #define CLASS_DLSPEC __declspec(dllimport)
#endif
#else
    #define CLASS_DLSPEC
#endif

class CLASS_DLSPEC classA
{
public:
    classA();

    void printMe();
};

#endif

"core" wird nun mit dem Makro EXPORT gebaut. Erweiterungen nicht, ABER (!!!) jetzt compiliert classB, also die "erweiterung" nur, wenn ich -lclassa angebe!!! Muss das sein? Schließlich sorgt das MAKRO für ein dllimport...

Tyvm

sothis_

Bombastus schrieb:

"core" wird nun mit dem Makro EXPORT gebaut. Erweiterungen nicht, ABER (!!!) jetzt compiliert classB, also die "erweiterung" nur, wenn ich -lclassa angebe!!! Muss das sein? Schließlich sorgt das MAKRO für ein dllimport...

yup, dass muss unter windows so sein, da müssen alle symbole zur linkzeit (mindestens über eine importbibliothek) vorhanden sein, auch wenn sie erst zur laufzeit dynamisch aufgelöst werden.

sothis_ schrieb:

Bombastus schrieb:

"core" wird nun mit dem Makro EXPORT gebaut. Erweiterungen nicht, ABER (!!!) jetzt compiliert classB, also die "erweiterung" nur, wenn ich -lclassa angebe!!! Muss das sein? Schließlich sorgt das MAKRO für ein dllimport...

yup, dass muss unter windows so sein, da müssen alle symbole zur linkzeit (mindestens über eine importbibliothek) vorhanden sein, auch wenn sie erst zur laufzeit dynamisch aufgelöst werden.

Ich danke herzlichst!

sothis_

ohne genau zu wissen was du vorhast, würde dich, denke ich, LoadLibrary() und GetProcAddress() interessieren. damit kannst du funktionszeigern zur laufzeit adressen von externen symbolen in dll's zuweisen. das macht in einem 'plugin' oder erweiterungsrahmen sinn, wenn eben zur linkzeit noch nicht alle symbole zur verfügung stehen.