shared C++ Library in C

fireblade1282

Mitglied
Hi Leute!
Wie funktioniert das mit Libraries die mit C++ erstellt wurden und C?
Eigentlich ist meine Frage ja noch allgemeiner zu verstehen, da es ja alle echten Libraries tangiert, die mit einer Objektsprache / Namespace-konzept-unterstützenden Sprache erstellt wurden...

Background: Ich habe auf einem AIX System eine .so Datei aus einem C++ Source mit xlC -G erzeugt in der nun die Funktionen liegen, die ich in einem C Projekt einbinden will (das c++ Prog hatte keine Objekte defineirt - nur einzelne Funktionen...). Das Linken der c files schlägt, sinngemäss mit ".Function not found"...

Ganz allgemein vermute ich, dass es am namespace liegt. Wenn ich in einem C++ Projekt eine Funktion Namespace1::Add und Namespace2::Add habe und exportiere die in eine shared library, müssten die doch beide dort ankommen. Ohne weitere Ahnung zu haben vermute ich, dass soetwas über prefixe gelöst wird, also dass die Einsprungstabelle des .so Files eine NS1_Add und NS2_Add oder soetwas anbieten muss.

Ganz allgemein habe ich aber eben wenig Ahnung von dieser Materie - wie verhält es sich zum Beispiel mit myObjekt->methode1()? Libraries werden vom Konzept her ja vermutlich nur Prototypen von einfachen Funktionen als Einstiegspunkt zulassen...

Kann mir hier jemand einen Tip geben, auch für Keywords zur weiteren Recherche würde ich mich freuen...!

- Andreas
 
Hi.
Hi Leute!
Wie funktioniert das mit Libraries die mit C++ erstellt wurden und C?
Eigentlich ist meine Frage ja noch allgemeiner zu verstehen, da es ja alle echten Libraries tangiert, die mit einer Objektsprache / Namespace-konzept-unterstützenden Sprache erstellt wurden...

Background: Ich habe auf einem AIX System eine .so Datei aus einem C++ Source mit xlC -G erzeugt in der nun die Funktionen liegen, die ich in einem C Projekt einbinden will (das c++ Prog hatte keine Objekte defineirt - nur einzelne Funktionen...). Das Linken der c files schlägt, sinngemäss mit ".Function not found"...

Ganz allgemein vermute ich, dass es am namespace liegt. Wenn ich in einem C++ Projekt eine Funktion Namespace1::Add und Namespace2::Add habe und exportiere die in eine shared library, müssten die doch beide dort ankommen. Ohne weitere Ahnung zu haben vermute ich, dass soetwas über prefixe gelöst wird, also dass die Einsprungstabelle des .so Files eine NS1_Add und NS2_Add oder soetwas anbieten muss.

Ganz allgemein habe ich aber eben wenig Ahnung von dieser Materie - wie verhält es sich zum Beispiel mit myObjekt->methode1()? Libraries werden vom Konzept her ja vermutlich nur Prototypen von einfachen Funktionen als Einstiegspunkt zulassen...

Kann mir hier jemand einen Tip geben, auch für Keywords zur weiteren Recherche würde ich mich freuen...!
Stichworte: C++ ABI / Name mangling

Du müßtest einen Wrapper schreiben (oder mit SWIG generieren) der dir die C++ Funktionen mit einem C-Funktionsnamen verfügbar macht.

Gruß
 
Hey deepthroat....D+A+N+K+E!

Das ist exakt die Problematik, ich hab mir schon gedacht, dass es intern über "Umbenennungsmechanismen" geregelt wird. "Name mangling" heisst das also.
Leider hab ich in der Wiki gelesen, dass das name mangling von den compilern verschieden gehandhabt wird....
bin student und mache ein praktikum an einem kleinen teilchenbeschleuniger... (nein, nicht am CERN :) ), die maschinen, die das hier alles steuern sind "exotisch", habe es mit einem alten AIX System zu tun und einer Art xlC Compiler... ich bin überhaupt schon froh, dass eine .so file am Ende des Compile/Link laufes vorlag. Gibt es eine Möglichkeit die Einsprungstabelle zu extrahieren um hinter das Geheimnis des hier vorliegenden name manglings zu kommen? Sprich ein kleines utility, damit ich nicht im hexeditor los surfen muss? Ich werde auch gleich mal losgoogeln, vielleicht finde ich ja was...

Many thanks!

- Andreas
 
Hi.

Unter Unix gibt es normalerweise das Programm "nm" welches die Symbole von Dateien auflistet. Habe aber keine Ahnung wie das unter AIX heißt..

Gruß
 
Hey.. ich muss mich nochmal melden, ich bekomme es nicht ganz hin.
Ich habe mittlerweile zum Test einfach eine h und eine c Datei, die eine Funktion int Add(int, int); deklarieren. Wenn ich eine so Datei daraus erzeuge, was endlich soweit funktioniert und diese mit nm anschaue finde ich:
.Add(int,int) T 268435752
.Add(int,int) T 268435816
.Add(int,int) t 268435816 40
Add(int,int) D 536871312 12
Add(int,int) d 536871324 4
TOC d 536871324
glink.s f -
mathlib.C f -

Nun habe ich ein c und ein c++ programm geschrieben, was die h datei einbindet und versuche das ganze zu kompilieren. mit cpp funktioniert das ganze reibungslos und es wird wirklich zur Laufzeit auf die lib zurückgegriffen. Bei der c Variante schlägt der linker fehl und meldet:

ld: 0711-317 ERROR: Undefined symbol: .Add
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.

Ich habe daraufhin von meiner Testanwendung in c und in c++ mal nur .o Dateien erzeugt und nm darauf losgelassen. Logischerweise ist die Add funktion nicht definiert. Allerdings steht in der c++ file:

.Add(int,int) U -
.main T 0
.printf U -
TOC d 128
main D 136 12
main d 128 4
mymathcpp.C f -

während in der c datei nur

.Add U -
.main T 0
.printf U -
TOC d 128
main D 136 12
main d 128 4
mymathc.c f -

zu finden ist.
Das heisst doch nun im klartext dass meine Funktion Add mit dem c kompiler als Add(int,int) exportiert wurde und meine c datei ein Add erwartet. Ich vermute dass c++ das (int,int) anhängt um zur Laufzeit dynamisch die richtige überladene Funktion zu finden, right? Für mich stellt sich nun die Frage: Kann ich beim exportieren / importieren von Funktionen eine Art alias definieren? Wie könnte ich c sonst beibringen eine mit c++ kompiler erstellte ABI zu nutzen? Ich müsste ja in der H Datei sonst den Prototypen als eine Art "Add(int, int)"(int, int) definieren, was ja offensichtlich quatsch ist... Ich bin im Moment etwas verwirrt. Es muss aber doch eine Möglichkeit geben.

Ich könnte mir nach allem was ich bisher hier erfahren habe vorstellen dass der Einsprungspunkt in wirklichkeit irgendetwas wie Add_ii oder so heisst. Das könnte ich durch eine Adapterartige Anpassung der c header datei ja auch umsetzen...

Kann mir da nochmal jemand auf die Sprünge helfen?
 
okay.. hat funktioniert.
nm zeigt schon die demangled names an.
nm -C <filename> zeigt das an was ich erwartet hatte..
Mit einer "adapter.h" hat dann das anbinden geklappt. Vielen Dank an alle die mitgeschrieben habe, ich schliesse das Thema!

THX
 
Zurück