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