[Buildroot] [RFC] package/go: switch to gcc go instead of go-bootstrap

[Buildroot] [RFC] package/go: switch to gcc go instead of go-bootstrap

[Christian Stewart via buildroot]

[-- Attachment #1.1: Type: text/plain, Size: 882 bytes --]

Hi all,

Go will soon require Go >= 1.16 to bootstrap.

See: https://github.com/golang/go/issues/44505

Go1.4 was the last version written in C.

Today, in Buildroot, we:

 - build gcc and/or use external toolchain
 - build go-bootstrap (go 1.4) with gcc
 - use go-bootstrap to build host-go

I propose that we switch to using Gccgo:

 - build gcc and/or use external toolchain
    - add flags to enable the "go" language in Gcc
    - GCC 11 or later
 - depend on the "go" language in Gcc to build host-go
 - use the gccgo compiler to bootstrap "host-go"

See: https://go.dev/doc/install/source#bootstrapFromGccgo

This will be more future proof, and also solve the issue of the upcoming
switch to requiring Go 1.11 or newer to compile the Go compiler.

If this looks good to everyone, I'll send a patch series.

Thanks & best,
Christian Stewart

https://github.com/skiffos/skiffos

[-- Attachment #1.2: Type: text/html, Size: 1531 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [RFC] package/go: switch to gcc go instead of go-bootstrap

[Thomas Petazzoni via buildroot]

Hello Christian,

On Wed, 25 May 2022 14:07:38 -0700
Christian Stewart <christian@paral.in> wrote:

> I propose that we switch to using Gccgo:
> 
>  - build gcc and/or use external toolchain
>     - add flags to enable the "go" language in Gcc
>     - GCC 11 or later

The problem I see with this is that many external toolchains do not
provide Go support. While this will probably evolve over time, this is
not something that we can reasonably require right now.

So I believe we probably don't have much other choice but to provide a
path that consists in building Go in multiple stages: first Go 1.4,
then a version of Go that is the last one that can be built with Go
1.4, and use that one to build the latest version of Go.

What do others think?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [RFC] package/go: switch to gcc go instead of go-bootstrap

[Joel Stanley]

On Wed, 25 May 2022 at 21:43, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Christian,
>
> On Wed, 25 May 2022 14:07:38 -0700
> Christian Stewart <christian@paral.in> wrote:
>
> > I propose that we switch to using Gccgo:
> >
> >  - build gcc and/or use external toolchain
> >     - add flags to enable the "go" language in Gcc
> >     - GCC 11 or later
>
> The problem I see with this is that many external toolchains do not
> provide Go support. While this will probably evolve over time, this is
> not something that we can reasonably require right now.

I use arm64 and ppc64le hosts for my buildrooting as they are the
fastest machines I have access to. Neither are supported by
go-bootstrap, so moving to gcc-go looks like a win for me.

Likewise, we don't have prebuilt toolchains for those host CPUs so the
question of external toolchains is not a factor.

I appreciate that my situation is unusual.

> So I believe we probably don't have much other choice but to provide a
> path that consists in building Go in multiple stages: first Go 1.4,
> then a version of Go that is the last one that can be built with Go
> 1.4, and use that one to build the latest version of Go.
>
> What do others think?

How much work is it to maintain both approaches: go-bootstrap for
setups where the host supports it and an external toolchain is in use,
and gccgo for the other situations?

Cheers,

Joel
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [RFC] package/go: switch to gcc go instead of go-bootstrap

[Thomas Petazzoni via buildroot]

Hello,

On Thu, 26 May 2022 02:17:19 +0000
Joel Stanley <joel@jms.id.au> wrote:

> > The problem I see with this is that many external toolchains do not
> > provide Go support. While this will probably evolve over time, this is
> > not something that we can reasonably require right now.  
> 
> I use arm64 and ppc64le hosts for my buildrooting as they are the
> fastest machines I have access to. Neither are supported by
> go-bootstrap, so moving to gcc-go looks like a win for me.

Indeed.

> Likewise, we don't have prebuilt toolchains for those host CPUs so the
> question of external toolchains is not a factor.
> 
> I appreciate that my situation is unusual.

As Yann Morin suggested in another e-mail, maybe we need to support
both situations:

 * Building Go in 3 stages when using an external toolchain that
   doesn't have Go support. This would mean building Go 1.4 with the C
   compiler, then building Go 1.16 with Go 1.4, and finally building Go
   latest with Go 1.16.

 * Building Go in 2 stages with gcc-go when using an internal toolchain
   (in which we can enable Go support) or an external toolchain that
   has Go support.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [RFC] package/go: switch to gcc go instead of go-bootstrap

[Christian Stewart via buildroot]

Thomas,

On Thu, May 26, 2022 at 6:46 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> On Thu, 26 May 2022 02:17:19 +0000
> Joel Stanley <joel@jms.id.au> wrote:
> > I use arm64 and ppc64le hosts for my buildrooting as they are the
> > fastest machines I have access to. Neither are supported by
> > go-bootstrap, so moving to gcc-go looks like a win for me.

> As Yann Morin suggested in another e-mail, maybe we need to support
> both situations:
>
>  * Building Go in 3 stages when using an external toolchain that
>    doesn't have Go support. This would mean building Go 1.4 with the C
>    compiler, then building Go 1.16 with Go 1.4, and finally building Go
>    latest with Go 1.16.
>
>  * Building Go in 2 stages with gcc-go when using an internal toolchain
>    (in which we can enable Go support) or an external toolchain that
>    has Go support.
>

As I also build on arm64 systems, I have a patch in my tree which
implements this:

https://github.com/skiffos/buildroot/commit/2df564c82081661f4a599998a276477929dd2a61

Previously submitted here (With your comments):

https://patchwork.ozlabs.org/project/buildroot/patch/20210622024337.3009417-1-christian@paral.in/

This implements using a host "/usr/bin/go" to bootstrap if
go-bootstrap cannot be built.

So there are actually three cases (in this priority order):

 - Build gccgo with buildroot toolchain -> golatest
 - Build go-bootstrap (C) with GCC -> go1.16 -> golatest
 - Build golatest relying on host /usr/bin/go installation.

Note that you can get the path to GOROOT with "$(go env GOROOT)"

So, we don't have to hardcode /usr/bin/go, but rather use whichever
"go" is in the PATH.

Thanks & best,
Christian Stewart
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [RFC] package/go: switch to gcc go instead of go-bootstrap

[Yann E. MORIN]

On 2022-05-25 23:43 +0200, Thomas Petazzoni spake thusly:
> Hello Christian,
> 
> On Wed, 25 May 2022 14:07:38 -0700
> Christian Stewart <christian@paral.in> wrote:
> 
> > I propose that we switch to using Gccgo:
> > 
> >  - build gcc and/or use external toolchain
> >     - add flags to enable the "go" language in Gcc
> >     - GCC 11 or later
> 
> The problem I see with this is that many external toolchains do not
> provide Go support. While this will probably evolve over time, this is
> not something that we can reasonably require right now.
> 
> So I believe we probably don't have much other choice but to provide a
> path that consists in building Go in multiple stages: first Go 1.4,
> then a version of Go that is the last one that can be built with Go
> 1.4, and use that one to build the latest version of Go.
> 
> What do others think?

I don't much like that we do need a multi-stage bootstrap, but this
looks like the measiest path forward. Except that the second-stage
bootstrap golang compiler will have to be installed "over" the
first-stage one, so we'd need to be careful whether they would install
a conflicting set of files.

Then, long-term, the gccgo path looks the most forward-looking solution,
but it is probably a bit more complex to handle, as the gcc package is
not trivial to extend (but just enabling go should not be *that* complex
either, hopefully).

For internal toolchains, we alrady have a flag to enable C++; for
externa l toolchains, we also have a flag for C++, D, and Fortran. We
can add a similar flag for go. People usign an external toolchain
without go support won't be able to use go packages, the same they won't
be able to use C++ with an external tolchain that laxk a C++ compiler
(even though this is pretty rare nowadays, tbh).

So, in the end, maybe the gccgo path is not that scary.

Still, I wonder what go level gccgo provides: is it a complete
replacement for the golang compiler? Will we have (or do we already
have) go packages that can't be built with gccgo but require golang?
Or the ther way around?

If so, do we plan on suporting that case (e.g.: depends on GO_IS_GOLANG,
or even: depends on GO_IS_GCCGO)?

Or do we plan on using gccgo just to build golang?

Regards,
Yann E. MORIN.

> Thomas
> -- 
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot