On Fri, Jun 12, 2020 at 01:41:41PM +0100, Ross Burton wrote: >... > With preferred provider set this can be used to build our own Go > toolchain. Yes, we're relying on a prebuilt binary but we're still > building the tools we actually use, so I don't see this as massively > different to using a host compiler. Does anyone have a strong > objection to bootstrapping our own Go by downloading the prebuilt > tools?
What about using the host Go (or gccgo)? Go 1.4 was released in 2014. gcc 5 provides an implementation of Go 1.4.2. Any host with gcc < 6 (released in 2016) is already required to use buildtools-extended in master, so adding Go (or gccgo) there should be sufficient to support ancient host distributions. >... > But looking forward, at this point we're downloading a perfectly good > Go toolchain to build a Go toolchain. This observation has already > led to meta-go-binary (https://github.com/YoeDistro/meta-go-binary), a > drop-in alternative for the Go recipes that simply use the pre-built > releases. It is perfectly good until the next CVE. > Also modern GCC can also build a Go frontend, so we could > just enable that in gcc-cross as we're always building a cross > compiler anyway. >... gccgo tends to be worse regarding features and performance. No objections to allowing users to additionally enable it (similar to Fortran), but it is not a full replacement. > Cheers, > Ross cu Adrian
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139438): https://lists.openembedded.org/g/openembedded-core/message/139438 Mute This Topic: https://lists.openembedded.org/mt/74838027/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
