Problem mit shared library
-
Hi,
ich habe Probleme beim Bauen einer shared library unter Linux mit g++.
Ziel ist es, einen Wrapper/Proxy als shared library fuer ein c++-Projekt zu schreiben, den ich unter Java ueber JNI einbinden kann. An Beispielprogrammen funktioniert das auch, aber beim eingentlichen Projekt leider nicht.
Wenn ich in Java auf die im c++-Methode zugreifen will, bekomme ich einen UnsatisfiedLinkError. Nicht, weil die library nicht gefunden wird, sondern weil er die Methode in der Library nicht findet.
Meine Vermutung ist nun, dass der Compiler (g++) die Namensgebung der Methoden meiner Klasse aendert.
Gibt es ein Programm, mit dem ich unter Linux in eine .so-Datei reingucken kann um herauszufinden, welche Methoden angeboten werden? Für DLLs unter Windows gibt es impdef, aber für Linux habe ich da nichts gefunden.
Alternativ wäre mir auch geholfen, wenn jemand mir sagen könnte, ob mein Compileraufruf falsch ist:
g++ -c -fPIC -I[Pfad zu Java]/include/ -I[Pfad zu Java]/include/linux/ -g -W -Wall -DDEBUG -I/home/s-save-s/progs/tcl8.0.5/include -I/home/s-save-s/progs/tk8.0.5/include -o obj/debug/libudiat-module.o src/libudiat-module.cpp g++ -shared -fPIC -I[Pfad zu Java]/include/ -I[Pfad zu Java]/include/linux/ -g -W -Wall -DDEBUG -Llib/debug obj/debug/libudiat-module.o obj/debug/ CorrelatingIndividual.o obj/debug/CorrIndvParameters.o obj/debug/ CorrIndvGenOpQueue.o obj/debug/CorrIndvGenOps.o obj/debug/GenoProtocol.o obj/debug/GenoCompNodesIdee1.o obj/debug/GenoCompNodesMetap.o obj/debug/GenoCompNodes.o -lpredict -ldatasrc -lgenetic -lmisc -o lib/debug/libudiat-module.so
Ich arbeite auf:
Linux, x86
Compiler: g++Vielen Dank für Eure Hilfe - ich hoffe, ich habe keine wichtige Information vergessen...
Gruss,
Christoph
-
intertag schrieb:
Gibt es ein Programm, mit dem ich unter Linux in eine .so-Datei reingucken kann um herauszufinden, welche Methoden angeboten werden? Für DLLs unter Windows gibt es impdef, aber für Linux habe ich da nichts gefunden.
nm
ich weiß aber nicht, nach welchem Schema die Namen entstehen und inwieweit man darauf Einfluss hat. Bei einer C-Library sieht das schöner aus.
-
Hi,
vielen Dank fuer Deine Antwort!
DrGreenthumb schrieb:
nm
Ich habe jetzt mit "nm --demangle <filename>" herausgefunden, dass meine Funktion in der shared library angekommen und der Name erhalten geblieben ist.
D.h. allerdings auch, dass ich mit meiner Vermutung nicht richtig lag - und nun keinen Ansatz mehr habe, warum er meine Methode nicht findet.
Naja, auf jeden Fall: Vielen Dank
Gruss,
Christoph
-
Wenn ich mich nicht irre dann ist jni ein c-api.
Dann kommst du mit nm --demangle nicht weiter.
Die Namen müssen ohne --demangle übereinstimmen.Kurt
-
Hi,
das Problem wurde gelöst:
Um dem C++-Compiler zu sagen, dass er die Namen nicht zerschreddern soll, wird ein extern "C" um die Funktion geschlungen:
extern "C" { // Anfang der eigentlichen Funktion JNIEXPORT jint JNICALL Java_Foo_Bar() {...} }
So, das wars. Dann liefert nm auch ohne --demangle die richtigen Funktionsnamen.
Viele Gruesse,
Christoph