-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go: prefers compiled pkg in second GOPATH root to rebuilding source in first #14192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for the report. Definitely sounds like something we need to fix. If you can make this happen on demand (even rarely), it would help to see the output of adding -x to the failing "go install ./cmd/...". |
I see now that you said you couldn't reproduce this with -x. I spent a while looking at the source code for cmd/go. All the package loading runs in a single goroutine. There are no races here. And I see no way that a reference to github.com/calmh/xdr could be resolved using the second GOPATH entry. Do you perhaps have some kind of cron script or other background builds running? The errors you got from the linker would make sense if maybe something was reinstalling the package files underfoot. |
You're probably right. I don't have anything periodic building things, but my editor does, and I probably had the XDR package open in the editor at the time. The above error (minus the panic) is trivially reproducible by having an xdr.a file in ~/pkg as it then won't try to build the package from Godeps/_workspace even though that's earlier in GOPATH. I think this is a known limitation with this method of building with dependencies. :/ |
Got one! This does look like a bug to me. Will investigate. Thanks.
|
CL https://golang.org/cl/19385 mentions this issue. |
I'm doing GOPATH-based vendoring, where my GOPATH is basically "$MyVendorDir:$HOME". This works perfectly fine most of the time. However in some cases, when the version of a package directly in GOPATH differs significantly from the vendored version, it doesn't. I think this highlights a race condition or other issue in the "go" tool when doing paralell compilation that doesn't show up when the vendored version of a package matches the "default" version.
These are my paths; there is a vendored github.com/calmh/xdr package, and I remove the pkg dirs in both GOPATH components before building:
When I then build, I hit this:
There's two strange things here. The first is the compile errors complaining about types not being defined in github.com/calmh/xdr. This is because it's using the version from ~/src (the second component of GOPATH), not the vendored one (the first component). The second is the panic, which doesn't look good but also doesn't always happen...
Looking at what it actually produced before erroring we can see that it built both the XDR package at the top level GOPATH and the vendored version (and they differ, in this case) - notice the timestamps on
xdr.a
and the fact that I nuked both pkg dirs before building:The XDR package is used by many things in "./cmd/..." - is there maybe some race condition around that when the build parallellizes things?
This all happens "now and then", and I finally solve it by touching source files, repeatedly running go install and so on to try to narrow it down ... and then it compiles just fine again... When writing this up, it started working when I used "go install -v -x" to find out what exact command builds the "wrong" version of the XDR package, without actually changing anything on disk, and now I cant reproduce it again. So I don't have a minimal reproducer, but there's something weird going on here. :(
The text was updated successfully, but these errors were encountered: