toolchain/gcc: Always build gccgo?

Jeffery To jeffery.to at gmail.com
Wed Mar 15 00:03:30 PDT 2023


Hello,

I'm considering looking into using gccgo to bootstrap the Go compiler
in the packages feed.

Currently, Go 1.4 (the last version written in C) is first built for
host, then it is used to build the newest Go for host. This host Go
compiler is then used to build the target Go package and other Go
programs.

There are some current and future limitations of using Go 1.4 to
bootstrap this process:

* Go 1.4 doesn't support certain platforms, most notably aarch64. (I
have worked around this by allowing the user to use their system Go as
bootstrap.)

* Upstream will likely start requiring a newer bootstrap version every
year[1]. Go 1.20 already requires Go 1.17 to bootstrap. Their plan
would have Go 1.22 require Go 1.20, Go 1.24 require Go 1.22, etc.

Using gccgo as bootstrap could potentially resolve all of these issues.

Before investigating this further, I would like to ask if there are
any disadvantages/opposition to always building gccgo? It is currently
optional and it would complicate this plan if it stayed optional.

[1]: https://github.com/golang/go/issues/54265

Thanks,
Jeff



More information about the openwrt-devel mailing list