From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13410 invoked by alias); 4 Apr 2005 21:27:31 -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 13374 invoked by uid 48); 4 Apr 2005 21:27:31 -0000 Date: Mon, 04 Apr 2005 21:27:00 -0000 Message-ID: <20050404212731.13373.qmail@sourceware.org> From: "mckinlay at redhat dot com" To: java-prs@gcc.gnu.org In-Reply-To: <20050404191026.20750.fitzsim@redhat.com> References: <20050404191026.20750.fitzsim@redhat.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/20750] libgcj needs a --with-java-home configure option X-Bugzilla-Reason: CC X-SW-Source: 2005-q2/txt/msg00033.txt.bz2 List-Id: ------- Additional Comments From mckinlay at redhat dot com 2005-04-04 21:27 ------- Yeah, in the case where java-gcj-compat is merged into libgcj (ie libgcj is set up to look like a JVM) then this option makes sense. libgcj would install its .jars and whatever other JVMish files applications expect to find into this directory, and set java.home accordingly. I don't see a reason why we couldn't go ahead and implement this on HEAD now, even though an external wrapper would still be needed for now to use ecj as javac. I so think it seems a bit non-intuitive to have --with-java-home just set a property and not actually install things into that directory, relying on an external package to actually populate it, however. We should at least install libgcj.jar into the directory given? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20750