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/98b9c7aaff2af4d19adfedac00b768d92530ce94http://autobuild.buildroot.net/results/bed228995ce3778720f991df9b41345a7c724a46http://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>
ed36d20daa