This is the mail archive of the
java-prs@gcc.gnu.org
mailing list for the Java project.
[Bug libgcj/21741] Need configure option to set java.library.path
- From: "fitzsim at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: java-prs at gcc dot gnu dot org
- Date: 7 Sep 2005 01:07:35 -0000
- Subject: [Bug libgcj/21741] Need configure option to set java.library.path
- References: <20050524194328.21741.green@redhat.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From fitzsim at redhat dot com 2005-09-07 01:07 -------
It turns out that Sun handles this in a strange way. To ensure that libjawt.so
is found automatically, Sun's java executable prepends $JAVA_HOME/jre/lib/i386
to LD_LIBRARY_PATH then re-exec's itself within the new environment.
I've just added a java command to java-gcj-compat that does the same thing only
exec's gij instead of re-exec'ing itself.
java.library.path has nothing to do with LD_LIBRARY_PATH except that its
user-visible value defaults to the contents of LD_LIBRARY_PATH. The
argument to -Djava.library.path= should be added to the dynamic library
loader's search path. So we also need to support running JAWT apps like this:
java -Djava.library.path=. gnu.classpath.examples.jawt.DemoJAWT
Currently this doesn't work. Though the initial problem is fixed now, I won't
close this bug until this usage pattern is also supported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741