Question

I am getting something like the following:

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)

This is even though I have set LD_LIBRARY_PATH to the path where I built my shared object.

Did I build that shared object wrong? This is the makefile I used to build the shared lib:

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}

Am I missing something with the way I am creating viewerNativeDLL.so?

If I do a ldd-d libviewerNativeDLL.so I get this:

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 I can clearly see they are missing, but how come I dont get any errors? What is the fix? I have linked in the static and shared libraries from xerces

edit: I am now actually getting this when I try to run it:

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

following the suggestion below, I changed the say I was linking to the libraries, which gives me this command and output:

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

I guess I will have to recompile xerces with fPIC?

Answer 1

I think the reason is the way you link to the libraries:

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

-L option is used to specify the search directories for the libraries, and the libraries themselves are specified using -l option.

It should probably be:

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

or just put the lib without -L

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

edit:

You may check with nm libxerces-c-3.1.so|grep ParseException (same for libxerces-c.a) if there’s such symbol defined. Make sure also that libxerces that you use for compilation (include paths -I) and the one you use for linking is the same.

Passing -Wl,-no-undefined when linking your library will help you see undefined symbols during linking rather than trying to load the library later.