C++-Wrapper um C-Lib: unresolved external symbols [GELÖST!]

[ponx]

Hallo zusammen!
Hier meine Problembeschreibung, in der Hoffnung dass jemand die Energie aufbringt, sich das epische Posting hier durchzulesen :? :

ich hab eine statische Library mit C-Funktionen. Damit man diese Funktionen auch ordentlich unter C++ nutzen kann, gibt's einen C++ Wrapper, der die ganzen Funktionen schön sauber in C++ Klassen verpackt und die C-Aufrufe kapselt. Mein Wrapper ist also selbst auch eine Library, und linkt selber die C-Funktionen, sodass man als Benutzer in seiner Applikation nur noch den Wrapper als einzige Library einbinden muss.
Den Wrapper kann ich ohne Fehlermeldung bauen, aber wenn ich jetzt eine Applikation bauen will, die diesen Wrapper benutzt, dann krieg ich beim Linken "unresolved external Symbols" für einige Funktionen der C-Library. Ich hab versucht rauszufinden, welche Eigenschaften die Funktionen haben, die betroffen sind:

1. Wenn meine C-lib eine Funktion X innerhalb von einer Funktion A aufruft, und ich kriege dazu den "unresolved external symbol X referenced in Function A", dann wird X auch in keiner anderen Funktion gefunden, die zusammen mit A in der gleichen Datei definiert ist.

2. Ich kann Funktion X innerhalb von manchen anderen Funktionen aufrufen, ohne den Fehler zu bekommen. Diese Funktionen sind dann in Dateien definiert, die dann wahrscheinlich nicht in dem Projekt benutzt werden. (Logisch, dann wird erst gar nicht gelinkt, schätz ich)

3. wenn ich Funktion X innerhalb der Funktionen A1 und A2 (wobei A1 und A2 zusammen in der gleichen Datei definiert sind) aufrufe, dann kriege ich den Fehler nur für die obere der beiden Funktionen. (ist das normal ?)

4. Wenn ich die C-Library, den Wrapper und die Applikation zusammen in der gleichen Solution habe, funktioniert alles mit genau den gleichen Projektdateien wunderbar ohne irgendwelche Fehler. Erst wenn ich die Applikation über eine getrennte Solution bauen will, gibt's die Probleme.

Der Wrapper scheint also manche .c Dateien in der C-Lib beim Bauen des Wrappers einfach nicht "durchzureichen".
Ich hab bei den Linker-Optionen des wrappers schon so ziemlich alles ausprobiert, ohne Erfolg. Ich werd noch mehr Infos sammeln, aber vielleicht hat jemand schon einen Verdacht ?

Für jede Idee sehr dankbar:

die alte frau ponx

[exploid]

...

[Krishty]

Mein Wrapper ist also selbst auch eine Library, und linkt selber die C-Funktionen, sodass man als Benutzer in seiner Applikation nur noch den Wrapper als einzige Library einbinden muss.

Was für eine Library ist dein Wrapper? Eine statische Lib oder eine DLL? Ersteres geht nämlich nicht, weil die Lib dann auch nur Verweise auf die C-Bibliothek enthält und ihr Code nicht in die neue Lib kopiert wird. Jedenfalls afaik.

[Aramis]

Ponx,

Statische Lib mit C-Funktionen? Dann sollten die Funktionsdeklarationen aus der Sicht eines C++-Compilers in

Code: Alles auswählen

extern "C" {
}

Blöcke verpackt werden. Nur so wählt der Linker die korrekten Importnamen (C++ unterstützt ja Überladungen und Namespaces, daher sind Einträge in der Exporttabelle einer DLL immer etwas kryptisch, da der Funktionsname alleine ja nicht eindeutig ist). Meist sieht das dann so aus:

Code: Alles auswählen

#ifdef __cplusplus
extern "C" {
#endif

int myfoo();
long mybar();

#ifdef __cplusplus
}
#endif

Natürlich vorausgesetzt, dass es sich bei den zu wrappenden Funktionen tatsächlich um in C implementierte und gelinkte Funktionen handelt.

Ich hab das in meiner Funktionssammlung für Graphic so gemacht das ich wie DirektX das ja auch macht virtuelle Klassen für Interfaces verwende.
siehe auch auf dieser Seite http://sppro.fkrauthan.de/2009/04/07/c- ... omment-143

Ich sehe einfach keinen Zusammenhang zum Thema .... zudem ist die verlinkte Erklärung eines Interfaces .. naja ... holprig :-)

[exploid]

...

[Aramis]

Genau das machen Interfaces unter Verwendung von virtuellen Klassen. Da ist der Zusammenhang.

Es geht hier um Linkerprobleme mit einem in C++ geschriebenen Wrapper, der auf ein C-API zugreift. Und zwar Linkerprobleme im Zusammenhang mit den gewrappten C-Funktionen. Ob dieser C++-Wrapper aus einzelnen Klassen oder intern implementierten Interfaces besteht, ist völlig egal ... denn es ist nicht das Problem. In beiden Fällen muss ein C-API aufgerufen, sprich hinzugelinkt werden. Das meine ich mit 'kein Zusammenhang zum Thema'.

[Jörg]

Mein Wrapper ist talso selbst auch eine Library, und linkt selber die C-Funktionen, sodass man als Benutzer in seiner Applikation nur noch den Wrapper als einzige Library einbinden muss.
Den Wrapper kann ich ohne Fehlermeldung bauen, aber wenn ich jetzt eine Applikation bauen will, die diesen Wrapper benutzt, dann krieg ich beim Linken "unresolved external Symbols" für einige Funktionen der C-Library. Ich hab versucht rauszufinden, welche Eigenschaften die Funktionen haben, die betroffen sind:
.....
4. Wenn ich die C-Library, den Wrapper und die Applikation zusammen in der gleichen Solution habe, funktioniert alles mit genau den gleichen Projektdateien wunderbar ohne irgendwelche Fehler. Erst wenn ich die Applikation über eine getrennte Solution bauen will, gibt's die Probleme.
.....
Der Wrapper scheint also manche .c Dateien in der C-Lib beim Bauen des Wrappers einfach nicht "durchzureichen".

Das scheint absolut darauf hinzuweisen, dass du den Bibliotheksgenerator nicht angewiesen hast, beide Bibliotheken (Wrapper und Original) zu kombinieren.
Schau' Dir doch mal die Doku zu 'LIB' an, siehe msdn.
Du kannst dir ja auch anzeigen lassen, was in den jeweiligen Bibliotheken 'drin' ist, zur Kontrolle.

[Krishty]

Weil ich selber ein wenig mit den Suchbegriffen spielen musste, um das zu finden:
http://msdn.microsoft.com/en-us/library/e17b885t.aspx

[exploid]

...

[ponx]

Jungs, es klappt !! Ihr seid meine Helden ! :'-)

Dass irgendwo das extern "c" fehlt hatte ich auch schon im Verdacht, aber da stimmte dann alles (Danke Aramis! jetzt hab ich auch endlich richtig kapiert wofür man das braucht)
Das Problem war letztendlich, dass zwei Dateinamen (.c / .cpp) vor der Endung gleich waren, und deshalb in zwei gleichnamige .obj Dateien compiliert wurden. Da ist er dann wohl durcheinandergekommen... fragt mich nicht, warum das keine Probleme verursacht hat, solange man's in der gleichen Solution baut. Was soll's, jetzt klappt alles.. vielen Dank an euch alle, vor allem an Jörg und Krishty mit dem LIB.exe Tipp ! Ich kannte das Tool gar nicht, das hat dann extrem geholfen.

In Partystimmung:
ponx