This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Failure to build gcc-3.4 20030909 Java sourcefiles: @libgcj.sourcelist: gcj: Internal error: Killed (program jc1)
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Jeff Sturm <jsturm at one-point dot com>, tromey at redhat dot com, java at gcc dot gnu dot org
- Date: Wed, 17 Sep 2003 02:00:34 -0500
- Subject: Re: Failure to build gcc-3.4 20030909 Java sourcefiles: @libgcj.sourcelist: gcj: Internal error: Killed (program jc1)
- Reply-to: gnustuff at thisiscool dot com
Hi All,
> > No. This was purely a cool optimization which I thought would speed
> > build time and be harmless. (Ha!) The old way worked just fine, albeit
> > slower on systems which had enough memory.
>
>Please either back out this patch or make it conditional on
>--enable-intermodule.
>
>Thanks,
>Andrew.
I was in the final stages of testing a conditional variant of this
patch which has the old behavior unless --enable-intermodule is
specified. When I tried building with, --enable-intermodule, the build choked
way upstream with an error that has since scrolled away.
Then I got to thinking: why should a flag which dictates how the compiler
is built be allowed to influence the way the libraries are built and/or
optimized? This seems to be an artificial association which unnecessarily
removes a degree of freedom.
May I define another flag called --enable-libgcj-multifile which
parameterizes this behavior? (I'm attempting a build with this now.)
Or do you want me to pull the plug on this? (I'm <i>this</i> close.)
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/