Hi, Background: Go is written in Go. This obviously presents an interesting bootstrapping problem.
The current build process is as follows: 1) Build Go 1.4 (from 2014) for native builds (go-native.bb). Go 1.4 was the latest release to be written in C, so this just needs a C compiler. 2) Using go-native, build a modern Go cross compiler (go-cross.bb). 3) Using go-cross you can now build target Go code. Success! However this solution isn't ideal as Go 1.4 only supports a limited number of hosts: i386, x86-64, and 32-bit Arm. We've 64-bit Arm machines in the autobuilder cluster, and we've seen people use PowerPC build hosts too. There are other ways to bootstrap Go: - Prebuilt toolchain. Go make binary releases for Linux on 32- and 64-bit x86 and Arm. Pros: works on more platforms. Cons: As Go has the nice feature that any Go compiler can target any platform/architecture, we're now downloading a full working Go to rebuild a full working Go. Why not just use this Go? - GCCGO. GCC has an optional Go frontend, which can be used to build Go. Pros: we already have a gcc recipe. Cons: as we don't really want to require gccgo on the host we'll need to build gcc-native, so why not just build gcc-cross with Go enabled? With the goal of minimal changes I wrote an alternative to go-native that uses the prebuilt binaries to build our own Go: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/go&id=4b2a5a12ab2d898ab4b1d8524b90f4e3938d01cf 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? I could either replace the existing go-native with this, or have both available so that users who don't want to rely on binaries and are happy with the limitation of Go 1.4 can stick with the source bootstrap. 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. 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. Does anyone have a strong opinion either way on this? Cheers, Ross
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139437): https://lists.openembedded.org/g/openembedded-core/message/139437 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] -=-=-=-=-=-=-=-=-=-=-=-
