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,
--
Jerry James
http://loganjerry.googlepages.com/

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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.
--
Jerry James
http://loganjerry.googlepages.com/

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list