ed36d20daa
The go toolchain can cross-compile by default. So most of the time, building a toolchain that supports a target, allows us to also build go binaries for the host. This is how support for host go packages was added: we use the same toolchain that was initially built only for target. But we might want to build a go binary for the host, when compiling a target for which go isn't supported. Then, building host-go will fail: by default, we build go for a specific target, and give the toolchain bootstrap scripts the cross compiler we'll use. This change modifies this behaviour: we only assume the go toolchain is cross-capable if we know the current target is supported. Otherwise this is a simple host go tool. We don't need to set any of the options needed for cross-compilation in that case. Thus, only set all the target-specific go options under a condition that the target arch is supported. The only option we still set is HOST_GO_CGO_ENABLED, and we always set it to enabled. It was also considered to create a separate package to build the go-for-host compiler which would be used for host-go-packages, but that would lead to a lot of duplication and is completely unnecessary. Fixes: http://autobuild.buildroot.net/results/98b9c7aaff2af4d19adfedac00b768d92530ce94 http://autobuild.buildroot.net/results/bed228995ce3778720f991df9b41345a7c724a46 http://autobuild.buildroot.net/results/3b3ea148165b96513ea511ee0d4adb334a6afac8 Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> |
||
|---|---|---|
| .. | ||
| 0001-build.go-explicit-option-for-crosscompilation.patch | ||
| Config.in.host | ||
| go.hash | ||
| go.mk | ||