From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23928 invoked by alias); 7 Dec 2008 22:48:33 -0000 Received: (qmail 23907 invoked by alias); 7 Dec 2008 22:48:32 -0000 Date: Sun, 07 Dec 2008 22:48:00 -0000 Message-ID: <20081207224832.23906.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/38438] build error in x86_64-unknown-linux-gnu/32/libjava In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "brian at dessent dot net" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2008-q4/txt/msg00091.txt.bz2 ------- Comment #2 from brian at dessent dot net 2008-12-07 22:48 ------- Subject: Re: New: build error in x86_64-unknown-linux-gnu/32/libjava It looks like somehow a rule is being run that isn't intended to ever actually be built. In libjava/Makefile.am there are these dummy rules copied and pasted for all the various tools. ## This is a dummy definition. grmiregistry_SOURCES = grmiregistry_LDFLAGS = --main=gnu.classpath.tools.rmiregistry.Main \ -rpath $(toolexeclibdir) -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) grmiregistry_LINK = $(GCJLINK) ## See jv_convert_LDADD. grmiregistry_LDADD = -L$(here)/.libs libgcj-tools.la grmiregistry_DEPENDENCIES = libgcj-tools.la Note that the _SOURCES is empty, which is why the link fails I guess. But these rules aren't supposed to be run as far as I can tell, because instead the binary .class files are checked into the tree and there are wrapper scripts that invoke the JVM with them. See libjava/classpath/tools/*.in. These wrappers should all have been created at the end of the classpath configure script execution. Are those wrappers not created for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38438