@aclements I've tried to debug it in #41101 but without much success. I will gladly provide access / bring it back online. I was planning to upgrade it to FreeBSD 12.2.

I think I've seen that failure when there was non-reproducible object files. I believe that there was a bug I introduced sometime during that pass/fail window that Cherry fixed, and that test should universally pass.

Personally I don't really like that stale check. I understand that it was there to catch the situation where someone is developing the linker locally, runs go test without go installing the linker first, which will get a wrong result. But I don't think it belongs to that particular test.

• it isn't useful for a builder or CI system (where the toolchain is always freshly built)
• if we want to do that, it'd probably better be an init function or TestMain.

It is true that it is weird that the linker is reported stale there (and not earlier by cmd/dist, if it is really stale). I could try to debug. But I also want to bring up the idea that we just remove that staleness check.

As I understand it, the test is already disabled for darwin-amd64 builders by https://golang.org/cl/223925.

@cherrymui

it isn't useful for a builder or CI system (where the toolchain is always freshly built)

For the moment, at least, the staleness check is useful in CI because it helps to detect cases where the build of the toolchain is somehow incomplete, corrupted, or out of sync (such as #33598 and #35740, which have yet to be diagnosed and fixed).

It's fine to remove the check if it isn't actually verifying a property relevant to the test, but if the staleness of cmd/link actually is relevant to the test then the check should stay — if we remove it, that just papers over some underlying problem that remains for the builder.

Sorry, I'd missed that this was already reported in #41101 (I searched around but somehow didn't find that). Let's close this as a dup and move the conversation over there.