FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 08-22-2008, 03:30 PM
"Jerry James"
 
Default Java guidelines questions

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
 
Old 08-22-2008, 03:34 PM
"Colin Walters"
 
Default Java guidelines questions

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
 
Old 08-25-2008, 03:17 PM
"Jerry James"
 
Default Java guidelines questions

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
 

Thread Tools




All times are GMT. The time now is 01:00 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org