ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot find libjvm.so without a -L flag. Is this deliberate or a bug?
Braden
On Fri, 27 Oct 2006 11:12:35 +0100, Andrew Haley wrote:
Braden McDaniel writes:
ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot find libjvm.so without a -L flag. Is this deliberate or a bug?
Please post a test case that shows this fault.
On this Fedora Core 6 x86_64 system, this program
#include <jni.h>
int main() { JNI_CreateJavaVM(0, 0, 0); }
cannot be linked with this command line:
$ gcc -ljvm -o libjvm-test libjvm_test.c /usr/bin/ld: cannot find -ljvm collect2: ld returned 1 exit status
This command line succeeds:
$ gcc -L/usr/lib64/gcj-4.1.1 -ljvm -o libjvm-test libjvm_test.c
Hi,
Braden McDaniel wrote:
ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot find libjvm.so without a -L flag. Is this deliberate or a bug?
This is deliberate. You should be dlopen'ing libjvm.so rather than linking to it directly. To locate it, use $JAVA_HOME/jre/lib/i386/client/libjvm.so like you would on other JVMs. java-1.4.2-gcj-compat symlinks /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so to libgcj's libjvm implementation.
Tom
On Sun, 29 Oct 2006 14:21:29 -0500, Thomas Fitzsimmons wrote:
Hi,
Braden McDaniel wrote:
ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot find libjvm.so without a -L flag. Is this deliberate or a bug?
This is deliberate. You should be dlopen'ing libjvm.so rather than linking to it directly. To locate it, use $JAVA_HOME/jre/lib/i386/client/libjvm.so like you would on other JVMs. java-1.4.2-gcj-compat symlinks /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so to libgcj's libjvm implementation.
Fair enough; but I don't want to force my users to set JAVA_HOME. Is this prefix build-time discoverable?
Hi,
Braden McDaniel wrote:
On Sun, 29 Oct 2006 14:21:29 -0500, Thomas Fitzsimmons wrote:
Hi,
Braden McDaniel wrote:
ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot find libjvm.so without a -L flag. Is this deliberate or a bug?
This is deliberate. You should be dlopen'ing libjvm.so rather than linking to it directly. To locate it, use $JAVA_HOME/jre/lib/i386/client/libjvm.so like you would on other JVMs. java-1.4.2-gcj-compat symlinks /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so to libgcj's libjvm implementation.
Fair enough; but I don't want to force my users to set JAVA_HOME. Is this prefix build-time discoverable?
If you're willing to require GCJ's implementation then you can count on libjvm.so being located at:
/usr/lib/jvm/java-1.4.2-gcj/jre/lib/$arch/client/libjvm.so
where $arch is the rpm architecture string. To print this string for the target system, use:
rpm --eval "%{_arch}"
If you'd like to require any JPackage JRE then the architecture string may be a little different (e.g., amd64 vs. x86_64) but the location will be:
/usr/lib/jvm/jre/lib/$arch/client/libjvm.so
If you'd like to support other types of JDK installations like /opt or /usr/java then you'll have to do a runtime search.
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Fitzsimmons wrote:
If you'd like to require any JPackage JRE then the architecture string may be a little different (e.g., amd64 vs. x86_64) but the location will be:
/usr/lib/jvm/jre/lib/$arch/client/libjvm.so
If you'd like to support other types of JDK installations like /opt or /usr/java then you'll have to do a runtime search.
There is also %{java_home} which uses java-functions to find JAVA_HOME, so you could do:
%{java_home}/jre/lib/amd64/client
or
%{_jvmdir}/java/jre/lib/amd64/server
- -- Sincerely,
David Walluck david@zarb.org
Thomas Fitzsimmons wrote:
Hi,
Braden McDaniel wrote:
On Sun, 29 Oct 2006 14:21:29 -0500, Thomas Fitzsimmons wrote:
Hi,
Braden McDaniel wrote:
ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot find libjvm.so without a -L flag. Is this deliberate or a bug?
This is deliberate. You should be dlopen'ing libjvm.so rather than linking to it directly. To locate it, use $JAVA_HOME/jre/lib/i386/client/libjvm.so like you would on other JVMs. java-1.4.2-gcj-compat symlinks /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so to libgcj's libjvm implementation.
Fair enough; but I don't want to force my users to set JAVA_HOME. Is this prefix build-time discoverable?
If you're willing to require GCJ's implementation then you can count on libjvm.so being located at:
/usr/lib/jvm/java-1.4.2-gcj/jre/lib/$arch/client/libjvm.so
On recent Fedora, perhaps; but I'm inclined not to depend on the java-1.4.2-gcj-compat in general since I don't know how widely it's coupled to gcj deployments.
What I'd like to support is preference for the libjvm relative to JAVA_HOME at run-time; but falling back to a location established for libjvm at build-time (if JAVA_HOME is not set at run-time).
where $arch is the rpm architecture string. To print this string for the target system, use:
rpm --eval "%{_arch}"
Not a solution for systems that aren't RPM-based. (But not a problem for me; autoconf solves this.)
If you'd like to require any JPackage JRE then the architecture string may be a little different (e.g., amd64 vs. x86_64) but the location will be:
/usr/lib/jvm/jre/lib/$arch/client/libjvm.so
If you'd like to support other types of JDK installations like /opt or /usr/java then you'll have to do a runtime search.
It's looking like my best option is to eke out all the information I can from libgcj.pc. Assuming libjvm.so is reliably installed in ${libdir}/gcj-${gcj_version} across distributions, I should be able to get what I need from it.
Braden
Braden McDaniel wrote:
Thomas Fitzsimmons wrote:
Hi,
Braden McDaniel wrote:
On Sun, 29 Oct 2006 14:21:29 -0500, Thomas Fitzsimmons wrote:
Hi,
Braden McDaniel wrote:
ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot find libjvm.so without a -L flag. Is this deliberate or a bug?
This is deliberate. You should be dlopen'ing libjvm.so rather than linking to it directly. To locate it, use $JAVA_HOME/jre/lib/i386/client/libjvm.so like you would on other JVMs. java-1.4.2-gcj-compat symlinks /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so to libgcj's libjvm implementation.
Fair enough; but I don't want to force my users to set JAVA_HOME. Is this prefix build-time discoverable?
If you're willing to require GCJ's implementation then you can count on libjvm.so being located at:
/usr/lib/jvm/java-1.4.2-gcj/jre/lib/$arch/client/libjvm.so
On recent Fedora, perhaps; but I'm inclined not to depend on the java-1.4.2-gcj-compat in general since I don't know how widely it's coupled to gcj deployments.
I think fairly widely: recent Debian, Ubuntu and Fedora at least. I think the above libjvm.so location is fairly reliable, if you ensure that your application package puts a packaging system requirement on java-gcj-compat (e.g. Requires: java-gcj-compat).
For FC-7 my plan is to merge java-1.4.2-gcj-compat completely into libgcj so that this distinction will not exist for subsequent releases.
What I'd like to support is preference for the libjvm relative to JAVA_HOME at run-time; but falling back to a location established for libjvm at build-time (if JAVA_HOME is not set at run-time).
where $arch is the rpm architecture string. To print this string for the target system, use:
rpm --eval "%{_arch}"
Not a solution for systems that aren't RPM-based. (But not a problem for me; autoconf solves this.)
If you'd like to require any JPackage JRE then the architecture string may be a little different (e.g., amd64 vs. x86_64) but the location will be:
/usr/lib/jvm/jre/lib/$arch/client/libjvm.so
If you'd like to support other types of JDK installations like /opt or /usr/java then you'll have to do a runtime search.
It's looking like my best option is to eke out all the information I can from libgcj.pc. Assuming libjvm.so is reliably installed in ${libdir}/gcj-${gcj_version} across distributions, I should be able to get what I need from it.
The problem with this approach is that this directory is versioned. So if you hard-code /usr/lib/gcj-4.1.1 into your application, it will break when the user upgrades to gcj 4.1.2. You could do a search for /usr/lib*/gcj-*, but this is something that java-gcj-compat is intended to do for you; it always keeps its unversioned libjvm.so symlink pointing to the right place.
Tom
On Fri, 03 Nov 2006 11:51:18 -0500, Thomas Fitzsimmons wrote:
Braden McDaniel wrote:
[snip]
It's looking like my best option is to eke out all the information I can from libgcj.pc. Assuming libjvm.so is reliably installed in ${libdir}/gcj-${gcj_version} across distributions, I should be able to get what I need from it.
The problem with this approach is that this directory is versioned. So if you hard-code /usr/lib/gcj-4.1.1 into your application, it will break when the user upgrades to gcj 4.1.2. You could do a search for /usr/lib*/gcj-*, but this is something that java-gcj-compat is intended to do for you; it always keeps its unversioned libjvm.so symlink pointing to the right place.
Sigh. That's a good point.
Once you fold java-gcj-compat into libgcj, what would you think of publishing a JAVA_HOME variable in the pkg-config metadata?
Braden McDaniel wrote:
On Fri, 03 Nov 2006 11:51:18 -0500, Thomas Fitzsimmons wrote:
Braden McDaniel wrote:
[snip]
It's looking like my best option is to eke out all the information I can from libgcj.pc. Assuming libjvm.so is reliably installed in ${libdir}/gcj-${gcj_version} across distributions, I should be able to get what I need from it.
The problem with this approach is that this directory is versioned. So if you hard-code /usr/lib/gcj-4.1.1 into your application, it will break when the user upgrades to gcj 4.1.2. You could do a search for /usr/lib*/gcj-*, but this is something that java-gcj-compat is intended to do for you; it always keeps its unversioned libjvm.so symlink pointing to the right place.
Sigh. That's a good point.
Once you fold java-gcj-compat into libgcj, what would you think of publishing a JAVA_HOME variable in the pkg-config metadata?
Yes, good idea. I'll do that.
Tom
java-devel@lists.fedoraproject.org
-
Andrew Haley -
Braden McDaniel -
David Walluck -
Thomas Fitzsimmons