gemeinsam genutzte Bibliothek kompiliert, hat aber Symbole undefined

Ich bin immer so etwas wie die folgenden:gemeinsam genutzte Bibliothek kompiliert, hat aber Symbole undefined

Exception in thread "main" java.lang.UnsatisfiedLinkError: no viewerNativeDLL in java.library.path 
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1734) 
at java.lang.Runtime.loadLibrary0(Runtime.java:823) 
at java.lang.System.loadLibrary(System.java:1028) 
at viewer.SarBufferedImage.<clinit>(SarBufferedImage.java:356) 
at viewer.viewerJPanel.<init>(viewerJPanel.java:34) 
at viewer.ViewerView.initComponents(ViewerView.java:457) 
at viewer.ViewerView.<init>(ViewerView.java:33) 
at viewer.ViewerApp.main(ViewerApp.java:21)

Dies ist, obwohl ich LD_LIBRARY_PATH auf den Pfad festgelegt haben, wo ich meine gemeinsames Objekt gebaut.

Habe ich dieses gemeinsame Objekt falsch erstellt? Dies ist die Make-Datei habe ich die gemeinsame lib zu bauen:

CPP  = g++ 
CFLAGS = -O3 -Wall -fopenmp -fPIC 
INC = -I ../../VC/readers/ -I../../VC/writers -I../../VC/common/ -I /home/dcole/software/xerces-c-3.1.1/src -I /home/dcole/software/java/jdk1.6.0_23/include -I /home/dcole/software/java/jdk1.6.0_23/include/linux 
LIB2 = -L/usr/lib64/ -L../../lib/IDT.a -L../../lib/Linux/libxerces-c.a -L../../lib/Linux/libxerces-c-3.1.so -lcurl -lidn -ldl -lssl -L../../lib/Linux/libfftw3f.a -lpthread 

all: ViewerNative.o 
${CPP} ${CFLAGS} -shared -o libviewerNativeDLL.so ViewerNative.o ${LIB2} 

ViewerNative.o: ViewerNative.cpp viewer_SarBufferedImage.h 
${CPP} ${INC} ${CFLAGS} -c ViewerNative.cpp ${LIB2}

Bin ich etwas mit der Art und Weise fehlt ich viewerNativeDLL.so erschaffe?

Wenn ich eine LDD-d tun libviewerNativeDLL.so ich diese:

undefined symbol: _ZTIN11xercesc_3_117SAXParseExceptionE (./libviewerNativeDLL.so) 
undefined symbol: _ZN11xercesc_3_117SAXParseExceptionD1Ev (./libviewerNativeDLL.so) 
linux-vdso.so.1 => (0x00007fff41f21000) 
libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007fc30bcd4000) 
libidn.so.11 => /lib64/libidn.so.11 (0x00007fc30baa2000) 
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc30b89d000) 
libssl.so.8 => /usr/lib64/libssl.so.8 (0x00007fc30b649000) 
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc30b42d000) 
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fc30b122000) 
libm.so.6 => /lib64/libm.so.6 (0x00007fc30ae9f000) 
libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x00007fc30ac92000) 
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc30aa77000) 
libc.so.6 => /lib64/libc.so.6 (0x00007fc30a709000) 
libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007fc30a4c4000) 
librt.so.1 => /lib64/librt.so.1 (0x00007fc30a2bb000) 
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007fc30a090000) 
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007fc309df4000) 
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007fc309bcd000) 
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fc3099ca000) 
libz.so.1 => /lib64/libz.so.1 (0x00007fc3097b5000) 
libssl3.so => /lib64/libssl3.so (0x00007fc309581000) 
libsmime3.so => /lib64/libsmime3.so (0x00007fc309357000) 
libnss3.so => /lib64/libnss3.so (0x00007fc309024000) 
libnssutil3.so => /lib64/libnssutil3.so (0x00007fc308e05000) 
libplds4.so => /lib64/libplds4.so (0x00007fc308c02000) 
libplc4.so => /lib64/libplc4.so (0x00007fc3089fe000) 
libnspr4.so => /lib64/libnspr4.so (0x00007fc3087c1000) 
libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x00007fc30859a000) 
/lib64/ld-linux-x86-64.so.2 (0x0000003e34a00000) 
libcrypto.so.8 => /usr/lib64/libcrypto.so.8 (0x00007fc308215000) 
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007fc308005000) 
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fc307dec000) 
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007fc307bd1000) 
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007fc3079c8000) 
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fc3077c6000) 
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fc30758e000) 
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc307370000) 
libfreebl3.so => /lib64/libfreebl3.so (0x00007fc307113000)

So kann ich deutlich sehen, sie fehlen, aber wie komme ich nicht bekommen, Fehler? Was ist das Problem? Ich verknüpft haben in den statischen und gemeinsam genutzten Bibliotheken von xerces

edit: Ich bin jetzt eigentlich diese bekommen, wenn ich versuche, es zu laufen:

$ java -Djava.library.path=/home/dcole/IM/work/ext/VC.viewer/viewerNativeDLL/ -jar viewer.jar 
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/dcole/IM/work/ext/VC.viewer/viewerNativeDLL/libviewerNativeDLL.so: /home/dcole/IM/work/ext/VC.viewer/viewerNativeDLL/libviewerNativeDLL.so: undefined symbol: _ZTIN11xercesc_3_117SAXParseExceptionE 
    at java.lang.ClassLoader$NativeLibrary.load(Native Method) 
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803) 
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728) 
    at java.lang.Runtime.loadLibrary0(Runtime.java:823) 
    at java.lang.System.loadLibrary(System.java:1028) 
    at viewer.SarBufferedImage.<clinit>(SarBufferedImage.java:356) 
    at viewer.viewerJPanel.<init>(viewerJPanel.java:34) 
    at viewer.ViewerView.initComponents(ViewerView.java:457) 
    at viewer.ViewerView.<init>(ViewerView.java:33) 
    at viewer.ViewerApp.main(ViewerApp.java:21)

edit2:

der Vorschlag unter folgenden, ich geändert das sage ich zu den Bibliotheken wurde die Verknüpfung, die mir diesen Befehl und Ausgang gibt:

g++ -O3 -Wall -fopenmp -fPIC -shared -o libviewerNativeDLL.so ViewerNative.o -L/usr/lib64/ ../../lib/IDT.a ../../lib/Linux/libxerces-c.a ../../lib/Linux/libxerces-c-3.1.so -lcurl -lidn -ldl -lssl ../../lib/Linux/libfftw3f.a -lpthread 
/usr/bin/ld: ../../lib/Linux/libxerces-c.a(PlatformUtils.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC 
../../lib/Linux/libxerces-c.a: could not read symbols: Bad value

ich denke, ich muss xerces mit fPIC neu kompilieren?

Quelle

2011-01-04 Derek

Ich denke, der Grund dafür ist die Art und Weise Sie zu den Bibliotheken verlinken:

-L../../lib/Linux/libxerces-c-3.1.so

-L Option verwendet wird, um die Suchverzeichnisse für die Bibliotheken zu spezifizieren, und die Bibliotheken selbst -l Option angegeben ist.

Es sollte wohl sein:

-L../../lib/Linux/ -lxerces-c-3.1

oder einfach den lib ohne -L

../../lib/Linux/libxerces-c-3.1.so

edit:

Sie mit nm libxerces-c-3.1.so|grep ParseException überprüfen können (gleich für libxerces-ca) wenn ein solches Symbol definiert ist. Stellen Sie sicher, dass libxerces, die Sie für die Kompilierung verwenden (include paths -I) und die, die Sie für die Verknüpfung verwenden, identisch sind.

Wenn Sie beim Verknüpfen der Bibliothek -Wl,-no-undefined übergeben, können Sie beim Verknüpfen undefinierte Symbole sehen, anstatt zu versuchen, die Bibliothek später zu laden.

Quelle

2011-01-04 17:12:40

Also tat ich das, und zeigte auf die libxerces-c.a und libzerces-c-3.1.so und ich gehe einen Fehler über nicht in der Lage, Symbole aus einer meiner Bibliotheken zu lesen. Ich habe diese lib mit -fPIC neu kompiliert und das Problem behoben, jetzt bin ich wieder bei Xerces mit einem Problem.Überprüfen Sie die Bearbeitung in der ursprünglichen Frage – Derek

Siehe meine Bearbeitung, vielleicht wird es nützlich sein. Stellen Sie sicher, dass Sie beide libxerces-Bibliotheken neu verknüpft haben. Gibt es einen Grund, sowohl mit libxerces-c-3.1.so als auch mit libxerces-c.a zu verlinken? Ist nicht nur einer von ihnen genug? –

Sie verknüpfen wieder gemeinsam genutzte Bibliotheken, z. -L ../../ lib/Linux/libxerces-c-3.1.so Sofern diese nicht enthalten sind, kann Ihre gemeinsame Bibliothek, die sie benötigt, nicht geladen werden.

Quelle

2011-01-04 17:11:00

gemeinsam genutzte Bibliothek kompiliert, hat aber Symbole undefined

Antwort

Verwandte Themen