ld doesn't know about location of libjvm

[Braden McDaniel]

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

[Andrew Haley]

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.

Andrew.

[Braden McDaniel]

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

-- 
Braden McDaniel                           e-mail: <braden(a)endoframe.com&gt;
<http://endoframe.com>                    Jabber: <braden(a)jabber.org&gt;

[Thomas Fitzsimmons]

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

[Braden McDaniel]

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?

-- 
Braden McDaniel                           e-mail: <braden(a)endoframe.com&gt;
<http://endoframe.com>                    Jabber: <braden(a)jabber.org&gt;

[Thomas Fitzsimmons]

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

[David Walluck]

-----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(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFFRhD9N5thZBYlTwkRAl6UAJ0ck5rwNB0lkEj+H21Pl5m5cx2QNQCePi+y
> a3Ioz5y2xfE9Pis/i/KGBu0=
> =2EO/
> -----END PGP SIGNATURE-----

[Braden McDaniel]

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

[Thomas Fitzsimmons]

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

[Braden McDaniel]

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                           e-mail: <braden(a)endoframe.com&gt;
<http://endoframe.com>                    Jabber: <braden(a)jabber.org&gt;

[Thomas Fitzsimmons]

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