разделяемая библиотека компилируется, но имеет неопределенные символы - PullRequest
1 голос
/ 04 января 2011

Я получаю что-то вроде следующего:

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)

Это даже при том, что я установил LD_LIBRARY_PATH на путь, по которому я построил свой общий объект.

Я построил этот общий объект неправильно? Это make-файл, который я использовал для создания общей библиотеки:

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}

Я что-то упускаю из-за того, как я создаю viewerNativeDLL.so?

Если я делаю ldd-d libviewerNativeDLL.so, я получаю это:

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)

Так что я могу ясно видеть, что они отсутствуют, но почему я не получаю никаких ошибок? Что это за исправление? Я связал в статических и общих библиотеках от xerces

edit: теперь я получаю это, когда пытаюсь его запустить:

    $ 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:

Следуя предложенному ниже предложению, я изменил выражение, которое я связывал с библиотеками, что дает мне эту команду и вывод:

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

Думаю, мне придется перекомпилировать xerces с помощью fPIC?

Ответы [ 2 ]

3 голосов
/ 04 января 2011

Я думаю, причина в том, что вы ссылаетесь на библиотеки: опция

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

-L используется для указания каталогов поиска для библиотек, а сами библиотеки указываются с помощью -loption.

Вероятно, это должно быть:

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

или просто поставить библиотеку без -L

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

edit:

Вы можете проверить с помощью nm libxerces-c-3.1.so|grep ParseException (то же самое для libxerces-ca), определен ли такой символ.Также убедитесь, что libxerces, которые вы используете для компиляции (включая пути -I) и тот, который вы используете для компоновки, одинаковы.

Передача -Wl,-no-undefined при компоновке вашей библиотеки поможет вам увидеть неопределенные символы при компоновкечем пытаться загрузить библиотеку позже.

0 голосов
/ 04 января 2011

Вы снова связываете разделяемые библиотеки, например, -L ../../ lib / Linux / libxerces-c-3.1.so Если все они не включены, ваша разделяемая библиотека, которая нуждается в них, не может загружаться.

...