I have some questions about the Java packaging guidelines with respect to native libraries [1]. JNI using packages must put the JAR and .so in %{_libdir}/%{name}, and use System.load() with a full path instead of using System.loadLibrary(). I guess this is for multilib situations, so you can have multiple JARs, each pointing to the correct .so. Since that full path can start with either /usr/lib or /usr/lib64, how have others generated that full path?
Wouldn't it be better to have a single JAR in /usr/share/java, and choose the correct path with the os.arch system property (which, annoyingly, is "amd64" with OpenJDK and "x86_64" with gcj on my machine)? We have to pass a full path to System.load() anyway, so I don't see the advantage of having the JAR under %{_libdir} in that case. Has there been any thoughts around providing a Fedora-specific JAR to hide the details of native library loading? (Maybe "Fedora.loadLibrary()"?)
Also, I know how to generate a .so with GCJ using aot-compile-rpm. How is this supposed to work for applications? Say I have a JAR file with a main method, and a wrapper script to invoke it in %{_bindir}. On a system that uses GCJ primarily, does that wrapper script do the right thing (invoke the gcj-compiled code)?
Finally, does anybody know why "gcj --target-help" sends this to stderr?
cc1: warning: command line option "-fbootclasspath=./:/usr/share/java/libgcj-4.3.0.jar" is valid for Java but not for C
References: [1] https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_file
Thanks,
On Fri, Aug 22, 2008 at 11:30 AM, Jerry James loganjerry@gmail.com wrote:
I have some questions about the Java packaging guidelines with respect to native libraries [1]. JNI using packages must put the JAR and .so in %{_libdir}/%{name}, and use System.load() with a full path instead of using System.loadLibrary(). I guess this is for multilib situations, so you can have multiple JARs, each pointing to the correct .so. Since that full path can start with either /usr/lib or /usr/lib64, how have others generated that full path?
Practically speaking you could just put it in /usr/lib because we will never support multilib Java.
However, if you want to put it on /usr/lib64 on x86_64 to make the filesystem prettier, take a look at how the javasqlite package does it: http://cvs.fedoraproject.org/viewvc/devel/javasqlite/
Has there been any thoughts around providing a Fedora-specific JAR to hide the details of native library loading? (Maybe "Fedora.loadLibrary()"?)
We just need to make the regular OpenJDK System.loadLibrary search both locations.
On Fri, Aug 22, 2008 at 9:34 AM, Colin Walters walters@verbum.org wrote:
Practically speaking you could just put it in /usr/lib because we will never support multilib Java.
However, if you want to put it on /usr/lib64 on x86_64 to make the filesystem prettier, take a look at how the javasqlite package does it: http://cvs.fedoraproject.org/viewvc/devel/javasqlite/
Thanks for the pointer. I'd like to abide by the guidelines so my package doesn't get dinged during review.
We just need to make the regular OpenJDK System.loadLibrary search both locations.
That would require putting the .so files in /usr/lib or /usr/lib64, not a subdirectory thereof, wouldn't it? I understood that the subdirectories are required because these .so files are not for general use, so we don't want ldconfig to know about them; they typically do not have sonames, for example. One possible solution is to collect all native .so files in /usr/lib/java and /usr/lib64/java, similar to how we collect jars. Then the System.loadLibrary for both OpenJDK and GNU Classpath would have to be modified to look in those locations.