This is the mail archive of the
mailing list for the GCC project.
Re: [RFT/RFA] Per-directory libjava builds (take 3)
- From: David Daney <ddaney at avtrex dot com>
- To: kcook at gcc dot gnu dot org
- Cc: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>, Richard Henderson <rth at redhat dot com>,GCJ-patches <java-patches at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 12 May 2005 12:16:23 -0700
- Subject: Re: [RFT/RFA] Per-directory libjava builds (take 3)
- References: <firstname.lastname@example.org>
Kelley Cook wrote:
Paolo, this looks very promising.
It brings up a thought: it seems that fixing all of this eliminate the
whole reason for the libgcj0_convenience library hack which recaused
the long command length regression shown in PR bootstrap/20155. Of
course that hack was just put in place to get around another hack for a
long command line in PR bootstrap/17222.
More specifically, this hunk:
libgcj0_convenience_la_SOURCES = prims.cc jni.cc exception.cc
link.cc defineclass.cc interpret.cc verify.cc \
- $(nat_source_files) $(math_c_source_files) $(java_source_files)
would be converted back to referring directly to libgcj_la.
Effectively reverting this patch
2005-02-15 Richard Henderson <email@example.com <mailto:firstname.lastname@example.org>>
* Makefile.am (libgcj_la_SOURCES): Move all sources ...
(libgcj0_convenience_la_SOURCES): ... here.
(libgcj_la_LIBADD): Add libgcj0_convenience.la.
(libgcj_la_DEPENDENCIES): Include libgcj_la_LIBADD.
* Makefile.in: Regenerate.
Unfortunately, I don't have a Alpha or MIPS host to test this theory
I don't have time to test the MIPS build with this right now, and I have
not really been following this patch.
This said, as long as we are not doing incremental linking MIPS should
be fine. (Assuming there is no GOT overflow with in the individual .o
If there is a GOT overflow in the individual .o, we should have a way to
break the groups of .java files into smaller groups.