From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7928 invoked by alias); 7 Sep 2005 01:07:36 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 7860 invoked by uid 48); 7 Sep 2005 01:07:35 -0000 Date: Wed, 07 Sep 2005 01:07:00 -0000 Message-ID: <20050907010735.7857.qmail@sourceware.org> From: "fitzsim at redhat dot com" To: java-prs@gcc.gnu.org In-Reply-To: <20050524194328.21741.green@redhat.com> References: <20050524194328.21741.green@redhat.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/21741] Need configure option to set java.library.path X-Bugzilla-Reason: CC X-SW-Source: 2005-q3/txt/msg00549.txt.bz2 List-Id: ------- 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