So, for..
class findhome { public static void main(String args[]) { System.out.println(System.getProperty("java.home")); System.out.println(System.getProperty("gnu.classpath.home.url")); System.out.println(System.getProperty("java.library.path")); } } javac findhome.java java findhome I have (on x86_64) ...
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre file:///usr/lib64 /usr/lib64/gcj-4.1.2
For something like OOo we have two sort of requirements,
at run time we'd like to dlopen libjvm.so, currently the approach I took for gcj was to stick lib/ARCH/client/libjvm.so onto the value of java.home. I guess from the output here searching through java.library.path is also plausible ?
The other requirement is at buildtime to link against libjawt.so and to find the java headers.
but for e.g. suse right now apparently the output of the above (for i386) is..
/usr file:///usr/lib/gcc/i586-suse-linux/4.2.1 /usr/lib/gcj-4.2.1
So what I'm wondering is if there is a canonical reference to what the various properties should refer to. i.e. are my assumptions just busted, or is e.g. the suse gcj misconfigured and if there is more correct way to find libjvm.so. And while I'm at it is there a good solid cross platform and cross java-impl test to find the correct include and link path to build against the java headers and link to libjawt and friends.
C.
Caolan McNamara wrote:
So, for..
class findhome { public static void main(String args[]) { System.out.println(System.getProperty("java.home")); System.out.println(System.getProperty("gnu.classpath.home.url")); System.out.println(System.getProperty("java.library.path")); } } javac findhome.java java findhome I have (on x86_64) ...
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre file:///usr/lib64 /usr/lib64/gcj-4.1.2
For something like OOo we have two sort of requirements,
at run time we'd like to dlopen libjvm.so, currently the approach I took for gcj was to stick lib/ARCH/client/libjvm.so onto the value of java.home.
Unfortunately, Java vendors do not provide libjvm.so in a standard location relative to JAVA_HOME. Your approach should work on RHEL- and Fedora-packaged GCJ 1.5.0, IcedTea and Sun JDKs. The BEA location is lib/ARCH/jrockit/libjvm.so and the IBM location is bin/classic/libjvm.so or bin/j9vm/libjvm.so.
I guess from the output here searching through java.library.path is also plausible ?
The other requirement is at buildtime to link against libjawt.so and to find the java headers.
The location of libjawt.so is JDK-dependent. GCJ 1.5.0, IcedTea, Sun and BEA install it as lib/ARCH/libjawt.so. IBM installs it as bin/libjawt.so. The headers are always in ${java.home}/../include.
but for e.g. suse right now apparently the output of the above (for i386) is..
/usr file:///usr/lib/gcc/i586-suse-linux/4.2.1 /usr/lib/gcj-4.2.1
So what I'm wondering is if there is a canonical reference to what the various properties should refer to. i.e. are my assumptions just busted, or is e.g. the suse gcj misconfigured
I'd say SuSE gcj is misconfigured. I had planned to add full support for JAVA_HOME to upstream GCJ; I got as far as adding a --with-java-home configure option which we set in Fedora. The SuSE package doesn't set it, so java.home defaults to $prefix.
and if there is more correct way to find libjvm.so. And while I'm at it is there a good solid cross platform and cross java-impl test to find the correct include and link path to build against the java headers and link to libjawt and friends.
See above. Because of the lack of Java deployment standards, your tests will need to know specifics about the JDK you're building with.
Tom
java-devel@lists.fedoraproject.org