go: find bootstrap automatically if go bin exists

[hgl]

Maintainer: @jefferyto
Compile tested: aarch64 master
Run tested: aarch64 master

Description:

When compiling go packages on a non-x86 host, users are very likely to hit the error that bootstrapping failed. This makes it less likely to happen by automatically find the host go bin if it exists.

The "go version" string is hardcoded, so it should be safe to anchor.

[jefferyto]

Thanks for this, but the use of the config option, without auto-detection, is by design.

The config option is modelled after the external toolchain options for the main buildroot. AFAIK they don't auto-detect those settings either.

As I see it, having a config option that requires manual intervention has two advantages:

• Requires conscious, informed action by the user
• Decreases the probability of building with a malicious Go compiler (if such a thing exists)

The documentation on using the config option, and perhaps why there is no auto-detection, can certainly be improved.

I'm open to discussing using auto-detection, and circumstances in the future may change and necessitate rethinking this design, but this is my current thinking.

[hgl]

Thanks for the clarification. The rationale is understandable. My 2 cents:

1. Since a failing toolchain is an anomaly, requiring an explicit config to use an external one seems logical, where in golang's case, bootstrapping 100% fails for some architectures, making the conscious choice more like a fatal error every user (on such architectures) has to fix.
2. Checking the version command and its output should drastically reduce the chance of it being a non-go binary. (Since this is about compiling OpenWrt, where users are expected to perform in a supporting environment, I personally don't think there is likely a malicious Go compiler, if so, explicitly specified /usr/bin/go is already the mostly likely one anyway. I do think there is a chance that go might be some non-go binary).

But again, I do understand the rationale of being strict, feel free to close this if you think the current method should not be changed.

[hgl]

@jefferyto would you accept this PR if the automatic finding is controlled by a flag?

I currently use nix to install all my build dependencies, which installs them in non-standard locations. Having to manually specify the non-standard paths in .config makes it brittle and cumbersome (the path actually isn't predicable, requiring some script to dynamically find it and write to .config). OpenWrt buildroot itself has no issues picking them up in $PATH, I wonder if go bootstrap could do the same?

If the automatic finding is something a user has to explicit opt in, it should address both points you mentioned. What do you think?

[jefferyto]

Upstream is switching to a model where they will require a newer bootstrap Go every year, see golang/go#54265.

I haven't figured out what to do with the build system here yet (continuing to extend the chain of bootstrap compilers from 1.4 -> 1.17 -> 1.20 -> ... isn't practical), that's why I haven't come back to this PR.

[hgl]

Maybe how user-provided bootstrapping is utilized is orthogonal to how the default bootstrapping is provided? If it's provided by the user, it's the user's responsibility to make sure the version is compatible. It should be possible to nail this case down before thinking about how the default bootstrapping should be designed?

[jefferyto]

One option for the default bootstrap is to use the default Go compiler on the system. Then there would be no need for a user-provided bootstrap Go.