Skip to content
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

cmd/go: go list std returns no packages #31313

Closed
josharian opened this issue Apr 7, 2019 · 4 comments
Closed

cmd/go: go list std returns no packages #31313

josharian opened this issue Apr 7, 2019 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@josharian
Copy link
Contributor

This was initially reported as dvyukov/go-fuzz#234. I've migrated it here as we investigate further, since this appears to be the correct home for it.

@saschagrunert reports that:

My distribution links the go sources into the go lib sources.

And provides this command and results:

$ go list -e -json -compiled=false -test=false -export=false -deps=false -find=true -- std
warning: ignoring symlink /usr/lib64/go/1.11/src/archive
warning: ignoring symlink /usr/lib64/go/1.11/src/bufio
warning: ignoring symlink /usr/lib64/go/1.11/src/builtin
warning: ignoring symlink /usr/lib64/go/1.11/src/bytes
warning: ignoring symlink /usr/lib64/go/1.11/src/compress
warning: ignoring symlink /usr/lib64/go/1.11/src/container
warning: ignoring symlink /usr/lib64/go/1.11/src/context
warning: ignoring symlink /usr/lib64/go/1.11/src/crypto
warning: ignoring symlink /usr/lib64/go/1.11/src/database
warning: ignoring symlink /usr/lib64/go/1.11/src/debug
warning: ignoring symlink /usr/lib64/go/1.11/src/encoding
warning: ignoring symlink /usr/lib64/go/1.11/src/errors
warning: ignoring symlink /usr/lib64/go/1.11/src/expvar
warning: ignoring symlink /usr/lib64/go/1.11/src/flag
warning: ignoring symlink /usr/lib64/go/1.11/src/fmt
warning: ignoring symlink /usr/lib64/go/1.11/src/go
warning: ignoring symlink /usr/lib64/go/1.11/src/hash
warning: ignoring symlink /usr/lib64/go/1.11/src/html
warning: ignoring symlink /usr/lib64/go/1.11/src/image
warning: ignoring symlink /usr/lib64/go/1.11/src/index
warning: ignoring symlink /usr/lib64/go/1.11/src/internal
warning: ignoring symlink /usr/lib64/go/1.11/src/io
warning: ignoring symlink /usr/lib64/go/1.11/src/log
warning: ignoring symlink /usr/lib64/go/1.11/src/math
warning: ignoring symlink /usr/lib64/go/1.11/src/mime
warning: ignoring symlink /usr/lib64/go/1.11/src/net
warning: ignoring symlink /usr/lib64/go/1.11/src/os
warning: ignoring symlink /usr/lib64/go/1.11/src/path
warning: ignoring symlink /usr/lib64/go/1.11/src/plugin
warning: ignoring symlink /usr/lib64/go/1.11/src/reflect
warning: ignoring symlink /usr/lib64/go/1.11/src/regexp
warning: ignoring symlink /usr/lib64/go/1.11/src/runtime
warning: ignoring symlink /usr/lib64/go/1.11/src/sort
warning: ignoring symlink /usr/lib64/go/1.11/src/strconv
warning: ignoring symlink /usr/lib64/go/1.11/src/strings
warning: ignoring symlink /usr/lib64/go/1.11/src/sync
warning: ignoring symlink /usr/lib64/go/1.11/src/syscall
warning: ignoring symlink /usr/lib64/go/1.11/src/testing
warning: ignoring symlink /usr/lib64/go/1.11/src/text
warning: ignoring symlink /usr/lib64/go/1.11/src/time
warning: ignoring symlink /usr/lib64/go/1.11/src/unicode
warning: ignoring symlink /usr/lib64/go/1.11/src/unsafe
warning: ignoring symlink /usr/lib64/go/1.11/src/vendor
go: warning: "std" matched no packages

This breaks go/packages.

@saschagrunert I have a couple of questions:

  • What distribution is it? Are you using it in any unusual way? (I'm trying to scope how widespread this issue may be.)
  • You reported using Go 1.12.1, but those symlinks all say go/1.11. Any idea why there is this disparity? Are the Go 1.12.1 std sources present, and if so, at what path? (And what does which go report?
  • Are the symlinks created by you or by your distribution? IIRC, the go tool has long ignored symlinks.

Thanks for your help tracking this down.

@josharian josharian added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Apr 7, 2019
@saschagrunert
Copy link

@josharian thank you for taking care of the issue and the report here!

  • What distribution is it? Are you using it in any unusual way? (I'm trying to scope how widespread this issue may be.)

I'm running openSUSE Tumbleweed, the (default) go package can be found here:
https://build.opensuse.org/package/show/openSUSE:Factory/go1.11

  • You reported using Go 1.12.1, but those symlinks all say go/1.11. Any idea why there is this disparity? Are the Go 1.12.1 std sources present, and if so, at what path? (And what does which go report?

Sorry for the confusion, I tried multiple versions of go, like this development version of go1.12:
https://build.opensuse.org/package/show/devel:languages:go/go1.12

I did not modify anything by hand until I found out that a usual download from https://dl.google.com/go/go1.12.2.linux-amd64.tar.gz and a manual modification of GOROOT/GOPATH works like a charm.

  • Are the symlinks created by you or by your distribution? IIRC, the go tool has long ignored symlinks.

It's by the distributions package. Do you think it would be possible to not ignore symlinks when running go list?

@josharian josharian added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Apr 8, 2019
@josharian
Copy link
Contributor Author

cc @bcmills @jayconrod for cmd/go

It is not clear to me whether the right fix here is in cmd/go or in the upstream distribution.

@jayconrod
Copy link
Contributor

I think this is an issue with the upstream distribution. Symbolic links cause a lot of issues with directory traversals, and they aren't supported on all platforms. If we followed them, it would very likely introduce bugs, and it would break projects that rely on the current behavior.

Note that in GOPATH mode, we do follow symbolic links for specific packages (e.g., I think go list flag would work in this situation), but we don't follow links while expanding wildcards or metapackages like std. In module mode, we actually remove symbolic links from module zip files before we load packages.

@josharian
Copy link
Contributor Author

@saschagrunert do you have any interest in opening an openSUSE issue?

In the meantime, it appears that you have found a workaround (download the package directly). Given that, and given that is doesn't appear there are any changes forthcoming on the cmd/go side, I'm going to close this. Feel free to comment if you think that we should re-open and discuss more.

@golang golang locked and limited conversation to collaborators Apr 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants