Pinned topicUnsatisfiedLinkError on AIX since Java 1.6 SR8 FP1

We have a program that uses JNI for the communication with a legacy system. It's working fine on several platforms, but unfortunately not on AIX with a Java version > 1.6 (SR8 FP1).

I've written a small test program that only tries to load the library (System.loadLibrary("jnilib")) to ensure that the problem isn't caused by any other part of our program. This test program successfully loads the library with Java 1.6 SR8 FP1 (fullversion: "JRE 1.6.0 IBM AIX build pap3260sr8fp1-20100624_01 (SR8 FP1)"), but it fails with Java 1.6 SR9 FP2 (fullversion: "JRE 1.6.0 IBM AIX build pap3260sr9fp2-20110627_03 (SR9 FP2)") or any newer version with an UnsatisfiedLinkError:

java.lang.UnsatisfiedLinkError: jnilib (No such file or directory)
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1018)
at java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:982)
at java.lang.System.loadLibrary(System.java:506)
at com.betasystems.jdmc.jni.JDMConnector.<clinit>(JDMConnector.java:626)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
at com.betasystems.jdmc.jni.JDMC.<init>(JDMC.java:80)
at com.betasystems.jdmc.rmi.JDMCServer.main(JDMCServer.java:813)

I've used the same command to start the test program for all tested Java versions, e.g. the Java version is the only difference.

I've already tried to change the library path from a relative to an absolute path, without success.
I've also recompiled the c-library as suggested here: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14878763&tstart=0, without success.

After searching the internet for a while I've learned that the message 'No such file or directory' doesn't necessarily mean that Java couldn't find the library itself. I might be caused by some other libraries that are used by our c-library that couldn't be loaded. Is there any way to the 'real reason' for this error?

Re: UnsatisfiedLinkError on AIX since Java 1.6 SR8 FP1

Can you try by pointing the environment variable LIBPATH to libjnilib.so and running the testcase?
export LIBPATH=/path/to/libjnilib/:$PATH

I remember coming across some code changes in this area around the Java6 SR9FP1 time frame - unfortunately i cant seem to get hold of the APAR's for you. I think it was something to do with MANDATING the use of LIBPATH while working with native libraries inside Java code.
Hope this helps.

Re: UnsatisfiedLinkError on AIX since Java 1.6 SR8 FP1

Can you try by pointing the environment variable LIBPATH to libjnilib.so and running the testcase?
export LIBPATH=/path/to/libjnilib/:$PATH

I remember coming across some code changes in this area around the Java6 SR9FP1 time frame - unfortunately i cant seem to get hold of the APAR's for you. I think it was something to do with MANDATING the use of LIBPATH while working with native libraries inside Java code.
Hope this helps.

>>>>>>text from the above link<<<<<<
You are recommended to compile your native methods (C or C++ functions called by Java) into AIX shared objects (dynamically loaded libraries). For example, if your native methods are stored in the file nm.c, you could create the shared object with the following command:
cc_r -qmkshrobj -q64 -I /usr/java6_64/include -o libnm.a nm.c
>>>>>>>end<<<<<

>>>>>>text from the above link<<<<<<
You are recommended to compile your native methods (C or C++ functions called by Java) into AIX shared objects (dynamically loaded libraries). For example, if your native methods are stored in the file nm.c, you could create the shared object with the following command:
cc_r -qmkshrobj -q64 -I /usr/java6_64/include -o libnm.a nm.c
>>>>>>>end<<<<<

I get these errors with the option '-qmkshrobj' independently from the used JDK, e.g. these symbols are also missing in the older version.
Are these undefined symbols the reason for the whole problem? And if they are: Why aren't we getting the same problem with Java 1.6 SR8 FP1?

I get these errors with the option '-qmkshrobj' independently from the used JDK, e.g. these symbols are also missing in the older version.
Are these undefined symbols the reason for the whole problem? And if they are: Why aren't we getting the same problem with Java 1.6 SR8 FP1?

like that, we need to find out the libraries for other symbols & need to pass the libraries to compiler/linker

cc -qmkshrobj -q32 ... -liconv <<other libraries>>

The reason for asking to build the library is to veryify whether "-G" option has any effect on the issue.

As per the definition of "-G" option, it enables runtime linking. http://pic.dhe.ibm.com/infocenter/comphelp/v121v141/topic/com.ibm.xlf141.aix.doc/compiler_ref/opt_g_upper.html?resultof=%22%2d%47%22%20%22%67%22%20

I have gone through the truss.log, I can see that the JVM is able to locate the library

like that, we need to find out the libraries for other symbols & need to pass the libraries to compiler/linker

cc -qmkshrobj -q32 ... -liconv <<other libraries>>

The reason for asking to build the library is to veryify whether "-G" option has any effect on the issue.

As per the definition of "-G" option, it enables runtime linking. http://pic.dhe.ibm.com/infocenter/comphelp/v121v141/topic/com.ibm.xlf141.aix.doc/compiler_ref/opt_g_upper.html?resultof=%22%2d%47%22%20%22%67%22%20

I have gone through the truss.log, I can see that the JVM is able to locate the library

like that, we need to find out the libraries for other symbols & need to pass the libraries to compiler/linker

cc -qmkshrobj -q32 ... -liconv <<other libraries>>

The reason for asking to build the library is to veryify whether "-G" option has any effect on the issue.

As per the definition of "-G" option, it enables runtime linking. http://pic.dhe.ibm.com/infocenter/comphelp/v121v141/topic/com.ibm.xlf141.aix.doc/compiler_ref/opt_g_upper.html?resultof=%22%2d%47%22%20%22%67%22%20

I have gone through the truss.log, I can see that the JVM is able to locate the library

Today I was able to take a look at this problem again and I found all missing symbols. I've added these symbols, build our library and now everything is working again!
It was neither necessary to build the library with a newer JDK, nor to set the LIBPATH. The new version of the library works with Java 1.5 as well as with Java 1.6 > SR8 FP1.

Many thanks for your help!
My problem might be solved, but I still don't really understand whats going on. Out library is just a jni-wrapper for another c-library. The missing symbols where caused by this c-library. Two functions have defined some global variables as 'extern' and everyone who uses one of these functions has to define these global variables. We aren't using these functions and therefore we haven't defined the global variables, what has caused the linker errors. To solve our problem I just had to define these global variables.
Why do we have to define these global variables for Java 1.6 > SR8 FP1? The corresponding functions are definitely not used and I always thought that the linker removes unused code.

Re: UnsatisfiedLinkError on AIX since Java 1.6 SR8 FP1

Today I was able to take a look at this problem again and I found all missing symbols. I've added these symbols, build our library and now everything is working again!
It was neither necessary to build the library with a newer JDK, nor to set the LIBPATH. The new version of the library works with Java 1.5 as well as with Java 1.6 > SR8 FP1.

Many thanks for your help!
My problem might be solved, but I still don't really understand whats going on. Out library is just a jni-wrapper for another c-library. The missing symbols where caused by this c-library. Two functions have defined some global variables as 'extern' and everyone who uses one of these functions has to define these global variables. We aren't using these functions and therefore we haven't defined the global variables, what has caused the linker errors. To solve our problem I just had to define these global variables.
Why do we have to define these global variables for Java 1.6 > SR8 FP1? The corresponding functions are definitely not used and I always thought that the linker removes unused code.

Because of Apar: IZ76085, the JVM/Java launcher has enabled with runtime linking from Java 1.6 SR9. As per the runtime linking, when an application(in our case JVM) & the module(your shared library) is enabled with the runtime linking(application using -brtl & the module using -G option), it expects to have all the symbols get resolved at the load time itself.

Previously, it was not the case as the application(JVM) not enabled with runtime linking & so no such constraint.

To know more about runtime linking. Refer
http://www.ibm.com/developerworks/aix/tutorials/linking102/section3.html