Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
cmd/dist: "moved GOROOT" test failing on plan9/386 builder #21016
CL 48550 added "moved GOROOT" test, which is failing on the plan9/386 builder. The plan9/386 builder is running as a buildlet on GCE, while the other builders are old-style builders.
Fails on iOS because CC_FOR_TARGET points to clangwrap.sh in the original GOROOT. We could fix that but it doesn't seem worth it. Fails on Android with "exec format error". I'm not sure why but I doubt it is interesting. Fails on Plan 9 because the original GOROOT is being preserved in some unknown way. This is issue #21016. Updates #21016 Change-Id: I4e7115d734fc7bf21e5a2ba18fb6ad0bfa31c735 Reviewed-on: https://go-review.googlesource.com/48650 Run-TryBot: Ian Lance Taylor <email@example.com> Reviewed-by: David du Colombier <firstname.lastname@example.org> Reviewed-by: Elias Naur <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org>
I think I figured out the issue.
In findGOROOT, the os.Executable function returns
Since the go tool is called directly from the tests, it should be accessible from the
I think it would be hard to argue that os.Executable is misbehaving here. /bin/go was run, and it returned /bin/go. findGOROOT is just making assumptions about program lookup that only hold on non-Plan 9 systems. It seems like findGOROOT just fundamentally can't work on Plan 9. Of course if the default builds used some canonical path like /sys/go or even /go, then users who want a different Go could bind their Go onto the canonical path. That might be the way forward if we want to support semi-movable GOROOTs on Plan 9. But I'm going to close this issue - the test failing - as working as intended.