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

["Yann E. MORIN" <yann.morin.1998@free.fr>]

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