The library itself is dependent on additional libraries that can't be
found at runtime. What makes you suspect jni.h specifically?
Use e.g. ldd libname.so to see the dependencies, and determine which
ones can't be resolved.
/gordon
--
Unfortunately I don't have ldd available on target :/
On build platform it does not work:
$ ldd libMyLib.so
../libMyLib.so:
ldd: ./libMyLib.so: Exec format error
I suspect jni.h because I worked with VM from another supplier before,
and jni.h (and other headers) was delivered together with VM.
This dedicated version of jni.h differs from standard Sun's jni.h
Full error message:
....
class load: java/util/jar/Attributes$Name
class load: MyLib/Application
class load: MyLib.Application from: file:XXXXX
class load: App
class load: App from: file:XXXXX
unknown relocation type
unknown relocation type
....
unknown relocation type
unknown relocation type
class load: java/lang/LinkageError
class load: java/lang/UnsatisfiedLinkError
Exception in thread "main" java.lang.UnsatisfiedLinkError: MyLib
(Unresolved symbols)
class load: java/lang/StackTraceElement[]
at java.lang.ClassLoader.loadLibraryWithPath(Unknown Source)
at java.lang.ClassLoader.loadLibraryWithClassLoader(Unknown
Source)
at java.lang.System.loadLibrary(Unknown Source)
at jsal.Application.<clinit>(Unknown Source)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(Unknown Source)
at java.lang.J9VMInternals.initialize(Unknown Source)