This is the mail archive of the
java-prs@gcc.gnu.org
mailing list for the Java project.
[Bug libgcj/38438] build error in x86_64-unknown-linux-gnu/32/libjava
- From: "brian at dessent dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: java-prs at gcc dot gnu dot org
- Date: 7 Dec 2008 22:48:32 -0000
- Subject: [Bug libgcj/38438] build error in x86_64-unknown-linux-gnu/32/libjava
- References: <bug-38438-3511@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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