Re: [OE-core] Bootstrapping Go
I don't actively use go anywhere, so don't have strong opinion either way, but from this description it looks like ASSUME_PROVIDED should be supported as well, if someone manages his "perfectly good Go toolchain" in his containers/OSs used in OE builds, then replacing it with another prebuilt "perfectly good Go toolchain" from someone else might be unnecessary step. On Fri, Jun 12, 2020 at 2:41 PM Ross Burton wrote: > 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 (#139439): https://lists.openembedded.org/g/openembedded-core/message/139439 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Bootstrapping Go
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Bootstrapping Go
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] -=-=-=-=-=-=-=-=-=-=-=-
