Re: drop <gcj 4.0 support

[Michael Koch]

On Fri, May 20, 2005 at 04:10:51PM +0200, Robert Schuster wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi.
> 
> Andrew Haley wrote:
> > Michael Koch writes:
> >  > On Fri, May 20, 2005 at 04:00:53AM +0200, Robert Schuster wrote:
> >   > > 
> >  > > As these errors do not happen with GCJ 4.0 I suppose the problem comes
> >  > > from a bug of the earlier GCJ versions. Do our GCJ people know about a
> >  > > problem where the compiler messed up the import functionality?
> >  > 
> >  > More then one. I take this now to start another discusion...
> >  > 
> >  > We should really support GCJ starting with version 4.0.0. We have
> >  > some problems with GCJ 3.3 and 3.4: either some stuff is not
> >  > implementable with them (see problems with inner classes in Swing)
> >  > or we added stupid workarounds for them that are not needed with
> >  > more sane java compilers like GCJ 4.0 or jikes. Dont get me wrong
> >  > these are not perfect too. But they are much better then GCJ 3.3
> >  > and 3.4.
> >  > 
> >  > So my call now: Let us update to depend on GCJ 4.0.0 as a minimum
> >  > when building with GCJ. The Building with jikes or other java
> >  > compilers should be unaffected by this.
> >  > 
> >  > What do you think?
> > 
> > Unless someone is going to start backporting gcj patches to 3.3, it
> > will be necessary to use a later compiler.  I can't see anyone
> > volunteering to do the work on 3.3.  In any case, we have lots to do
> > -- fixing 3.3 isn't a great use of anyone's time.
> > 
> I just want to note that there is always the possibility to use Jikes.
> 
> Michael, how should we handle gcj <4 from now on?
> 
> a) Print an error message when detected as only available compiler and
> abort.
> 
> b) Print a warning ("gcj 3.3 is unsupported - compilation may break")
> but continue compilation?

Aborting when --with-gcj is used and the version of gcj is too old.
WE already do this for gcj < 3.3 afaik so the changes should be minimal.

> And to our GCC freaks: How has libstc++ handled such problems? (I assume
> that they had similar issues with g++ here.)

libstdc++ is part of GCC and assumes that all build from the same tree.


Michael
-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/