[fedora-java] Re: ld doesn't know about location of libjvm

[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