See also e.g.

#49749
#49102

And thanks in advance @cherrymui !

Absolutely fine, already did do so 😃

This followup was created to improve the error message though, right?

This followup was created to improve the error message though, right?

Yes, that's right. I lost a day trying to hunt down the root cause of this, thinking it was a problem in our (unconscionably complicated Yocto-ed) toolchain. No-one but myself to blame really, but a better error message would have helped a lot.

Something along the lines of "cross-compiling with race detector requires manual intervention; see http://blahblahblah" :)

In an ideal world, the compiler would quietly download the missing syso for you, but I realise that the risk/reward there is probably small :D

@DryHumour no need to blame yourself. It is indeed a place that needs improvement :)

We could do the detection in the linker, when -race is specified and certain symbols are missing.

I'm thinking if it is better to do it in the go command, where when it does a go build -race, it can error out if runtime/race/race_GOOS_GOARCH.syso does not exist. @bcmills would that be too much for a special case in cmd/go?

I think it would be fine to have a special case, if we're careful about how we factor it.

Perhaps we could put the detection logic in cmd/internal/sys alongside sys.RaceDetectorSupported?

In some sense this is really just a finer-grained answer to that question: “is the race detector supported for this platform in general?” vs. “is the race detector supported for this platform with your installation of the toolchain?”

(Perhaps sys.RaceDetectorInstalled?)

Without having any idea, my gut feeling also thinks that the go command would be the right place to implement such a warning :-)

Yes, just emitting a message e.g. pointing to a wiki page when cross-compiling and -race is specified would be lovely. Don't even really need to abort the build or do anything fancy with risk for potential unintended consequences: I realise that this is probably something of a corner case for general Go use.

Just pointing in the right direction would help clueless newbs like me who desperately try (and fail) to get their cross-toolchain extld to link cgo with libtsan.... (And, yes, I probably deserved what I got for making the myriad assumptions to even draw that ridiculously flawed conclusion. I feel pretty sheepish in hindsight....) :-)