Community
Participate
Working Groups
The AIX JVM has an unusual property not seen on other platforms related to naming of libraries that the JVM can load via java.lang.System.loadLibrary(). In this example I have a native library named test. On most platforms this maps to exactly one library name, usually libtest.so. On the AIX JVM it can map to either libtest.a or libtest.so. If the library is on the java.library.path then they will be loaded automatically. However this does not happen if the java.lang.ClassLoader.findLibarary() method is called. When findLibrary is called what the library name passed into the findLibrary method is "test". The classloaders then convert that to the platform specific name by calling System.mapLibraryName(). In the case where findLibrary is being called this will return libtest.a, but if the library is called libtest.so (which is acceptable and common on the AIX platform) then the classloader will not currently allow the library to be loaded. For the AIX platform the classloader itself needs to look for libtest.a and if it cannot find it try replacing .a with .so instead. Without this support it will not be possible to load native libraries on AIX that end in .so rather than .a. Alasdair
As you mentionned we rely on System.mapLibraryName to get the name of the library to load, however it seems that this method is not sufficient for AIX since two values are valid. I suggest opening a bug report against Sun. In the meantime, we can probably create an AIX specific ClassLoadingHook to address this issue.
Created attachment 37696 [details] Patch contributing a new classloading hook for AIX Note that the patch does not include a modified version of the hookconfigurator.properties file because I'm not sure if we want to include this directly in the fwk or make it available as a separate download.
fewer hooks the better since they all impact startup time, disk footprint and in memory footprint. Is there a more surgical change that could be done that just updates the code we already have? Not sure why there are references to HPUX in there or why Constants is being used with a fully qualified name. Side note, this was reported against 3.1.2 just now. Why is this a new problem? Is it a new version of the VM? What is the AIX norm? That is, how do other Java programs work? BTW, IBM produces the JRE for AIX. Perhaps Alasdair can walk over to the AIX team and press the issue...
Jeff, This "problem" is not new, it has existed on the 1.4.2 and 1.5 JDKs on AIX. This is the AIX norm, I guess no one has hit the problem before. Also the native libraries in swt for AIX all end in the .a extension. Alasdair
thanks for the update. if it is not new onthe AIX vms, what is new in Eclipse that has suddenly caused this problem to show up? Sorry but I am just a bit confused as to which (.a or .so) is the norm and who is using what and which is the problem.
Hi, There is nothing new in Eclipse that shows this problem. I was trying to create an OSGi bundle that contained a native library that contained a native library with a .so extension and it did not work. It was not possible to change this to a .a extension, so I have found a new solution, but I thought it would be worth seeing if the OSGi classloader could be aware of this problem and help resovle it. Alasdair
*** Bug 130118 has been marked as a duplicate of this bug. ***
Ah, thank you for this analyze. I thought the issue comes from me. In which version of Eclipse will this issue be resolved ? Thank you.
This will likely be fixed in RC1, however the shape of the fix is yet to be decided. Also could you please try the patch and let us know if this solves the problem.
We should avoid adding new hook classes etc if at all possible. We need to understand the norms and expectations here. They are still not clear to me. We have been running fine on AIX for quite some time. What is different about this case? (yes, theuse of a .so is different but why is there a .so if the norm is .a? Is this something new? Common? addressable in another way? A VM thing?, ...)
Alasdair has set me straight on the details of the problem and why it is a problem. This may have been said but I missed it so will repeat it here for history. Turns out that for normal Java code on AIX .a and .so works because System.mapLibraryName actually goes out an looks on the disk at the java.library.path to see what is there and returns whichever it found. in our case the libs are never there as they are in the bundles so mapLibraryName just returns a default answre of .a. The proposed patch largely has the needed fix but I will paraphrase here and suggest that this code just go in the normal hook rather than having a duplicate hook for AIX At the end of EclipseClassLoadingHook.findLibrary() put the following... String result = searchVariants(data, libName); if (result == null && on AIX) result = searchVariants(data, libName.replace(".a", ".so")); return result; Clearly the code needs to be better than this but it conveys the idea. We can certainly do this in 3.2. The same changes would likely apply to 3.1.x (though on different classes of course)
Created attachment 38351 [details] patch Here is a patch that adds support for searching additional library extensions into the BaseClassLoadingHook and the EclipseClassLoading hook. A new configuration property is added osgi.framework.library.extensions (suggest a new name plz). This property specifies additional library file extensions that should be searched. For example on AIX you could specify osgi.framework.library.extensions=".a" This specifies extensions in addition to the one returned by System.mapLibraryName.
I released a fix. The final fix is a modified version of the attached patch. - There was a bug in the initialization of the LIB_EXTENSIONS constant. - changed code to do normal search before mapping the library name to the extra specified extensions.
