This is the same idea as OpenBSD's O_BELOW resp. F_BELOW. Perhaps the API can be designed to match OpenBSD's?

But the easiest way to prevent that is simply to ensure that we keep providing the latest go release. As long as the minor doesn't exceed what's in the ports tree, that toolchain-downloading behaviour will never trigger.

You're missing the point, I suspect. Go no longer has that problem. Go will no longer try to build go121 programs with a go124 stdlib. It will build go121 with a feature set identical go121, and this happens transparently and automatically. Go designed it this way so that there is never a need for multiple go versions. Technically we could leave go122 in the ports tree and it'd build all future Go programs.

I already have a more comprehensive patch prepared that fixes this issue and some others. It is currently undergoing build testing.

In D50065#1144599, @kevans wrote:

In D50065#1144517, @glebius wrote:

I'd vote against putting it back. I submitted patch to the port upstream.

Was that the only port identified that depended on it?

Looks reasonable.

Would be nice to keep CLLADDR around for compatibility. Had to patch net-mgmt/ipgen as it uses this macro; would have been nice if I didn't have to.

Build test on i386 and armv7 FreeBSD 14.2 passed.

Please make sure to MFH this change when it lands. My test builds on armv7 and i386 are still ongoing.

I disagree with this step.

I didn't check as I don't have graphics on my build box and no account to try the login prompt with.

Builds fine for me.

This looks like a reasonable patch. Does a test build succeed? Does the maintainer approve?