1 |
On Tue, Nov 03, 2015 at 03:09:52PM +0000, James Le Cuirot wrote: |
2 |
> On Tue, 3 Nov 2015 08:56:29 -0600 |
3 |
> William Hubbs <williamh@g.o> wrote: |
4 |
> |
5 |
> > As has been pointed out in the thread so far, gcc-5 only supports |
6 |
> > go-1.4. dev-lang/go is at 1.5, so really the only thing that should be |
7 |
> > built with gccgo is dev-lang/go. Also, the golang eclasses are |
8 |
> > designed to work with dev-lang/go, so they do not need a dependency |
9 |
> > on gccgo. |
10 |
> > |
11 |
> > I see gcc-5[go] as a separate Go compiler, but it will always be |
12 |
> > behind dev-lang/go, so you will have things that build with |
13 |
> > dev-lang/go but not gccgo. Also, the commands to do the builds are |
14 |
> > completely different depending on which one you are using. |
15 |
> |
16 |
> This is a lot like the situation with gcc's gcj and the icedtea Java |
17 |
> JDK. The arguments are quite different so we have a wrapper script |
18 |
> packaged as gcj-jdk. gcj only supports Java 6(ish?) and there are |
19 |
> other compatibility issues though so we no longer support it as a |
20 |
> general purpose JDK. Its only use is for bootstrapping icedtea. Now |
21 |
> that Java has been open sourced and gcj has fallen so far behind, gcc |
22 |
> are planning to scrap it so icedtea will need to find another way to |
23 |
> bootstrap (probably JamVM) if it isn't to rely on prebuilt versions of |
24 |
> itself. |
25 |
|
26 |
I am definitely not against the patch to enable gccgo on all platforms. |
27 |
This actually may make it possible for us to bootstrap dev-lang/go on |
28 |
all of the platforms gccgo can be built on. |
29 |
|
30 |
However, the situation with gcj sounds very similar to what is happening |
31 |
with Go, and I want to take the same approach. |
32 |
|
33 |
I do not recommend using gccgo as a general-purpose Go compiler. I may |
34 |
be able to use it to bootstrap the general purpose compiler, which is |
35 |
dev-lang/go, but That will probably be about it since it will always |
36 |
be behind. |
37 |
|
38 |
I am against virtual/go. If you want to enable gccgo go ahead, but |
39 |
please do not create virtual/go. Gccgo should only be used in special |
40 |
cases, for example bootstrapping dev-lang/go. |
41 |
|
42 |
William |