On Tue, Nov 03, 2015 at 03:09:52PM +0000, James Le Cuirot wrote:
> On Tue, 3 Nov 2015 08:56:29 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > As has been pointed out in the thread so far, gcc-5 only supports
> > go-1.4. dev-lang/go is at 1.5, so really the only thing that should be
> > built with gccgo is dev-lang/go. Also, the golang eclasses are
> > designed to work with dev-lang/go, so they do not need a dependency
> > on gccgo.
> > 
> > I see gcc-5[go] as a separate Go compiler, but it will always be
> > behind dev-lang/go, so you will have things that build with
> > dev-lang/go but not gccgo. Also, the commands to do the builds are
> > completely different depending on which one you are using.
> 
> This is a lot like the situation with gcc's gcj and the icedtea Java
> JDK. The arguments are quite different so we have a wrapper script
> packaged as gcj-jdk. gcj only supports Java 6(ish?) and there are
> other compatibility issues though so we no longer support it as a
> general purpose JDK. Its only use is for bootstrapping icedtea. Now
> that Java has been open sourced and gcj has fallen so far behind, gcc
> are planning to scrap it so icedtea will need to find another way to
> bootstrap (probably JamVM) if it isn't to rely on prebuilt versions of
> itself.

I am definitely not against the patch to enable gccgo on all platforms.
This actually may make it possible for us to bootstrap dev-lang/go on
all of the platforms gccgo can be built on.

However, the situation with gcj sounds very similar to what is happening
with Go, and I want to take the same approach.

I do not recommend using gccgo as a general-purpose Go compiler. I may
be able to use it to bootstrap the general purpose compiler, which is
dev-lang/go, but That will probably be about it since it will always
be behind.

I am against virtual/go. If you want to enable gccgo go ahead, but
please do not create  virtual/go. Gccgo should only be used in special
cases, for example bootstrapping dev-lang/go.

William