Navigation Menu

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

Jump to bottom

cmd/go: go build ./... may or may not write executable to disk depending how many packages the import path pattern matches #39515

Open
xyzst opened this issue Jun 11, 2020 · 2 comments
Open

cmd/go: go build ./... may or may not write executable to disk depending how many packages the import path pattern matches #39515

xyzst opened this issue Jun 11, 2020 · 2 comments
Labels
GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@xyzst
Copy link

xyzst commented Jun 11, 2020 •
edited

What version of Go are you using (go version)?

$ go version
go version go1.14.3 darwin/amd64

Does this issue reproduce with the latest release?

Issue is reproduced with the latest release.

What operating system and processor architecture are you using (go env)?

OS: macOS Catalina (10.15.5)

go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/cest-la-vie/Library/Caches/go-build"
GOENV="/Users/cest-la-vie/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/cest-la-vie/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.14.3/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.14.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/cest-la-vie/fsociety/dev/go/go-build-issue/L1/M0/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/qc/_15tg89d2xg2blsddq6f9zkc0000gn/T/go-build913708293=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I am trying to build a go module using go build ./... in the same directory as go.mod. It works fine when there's only a single go package (main) and file. But adding another package and file, referencing those functions in main, and executing the aforementioned command does not generate the executable.

I have a very basic go project that reproduces this issue (includes instructions): https://github.com/xyzst/go-build-bug

What did you expect to see?

An executable should be generated in the same directory as go.mod

What did you see instead?

The binary is not generated and I am not able to locate it anywhere.

There are workarounds available:

  • go install ./... still works as intended and the binary is found in the expected location at $GOPATH/bin
  • go build ./path/to/go/file/with/mainpkg.go will generate the binary as expected
@dmitshur
Copy link
Contributor

This go build behavior is very old (and in my opinion unfortunate, but I don't know if it's viable to improve). It's a consequence of go build changing behavior depending on whether its given a single command or many packages. This is documented at https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies:

When compiling a single main package, build writes the resulting executable to an output file named after the first source file ('go build ed.go rx.go' writes 'ed' or 'ed.exe') or the source code directory ('go build unix/sam' writes 'sam' or 'sam.exe'). The '.exe' suffix is added when writing a Windows executable.

When compiling multiple packages or a single non-main package, build compiles the packages but discards the resulting object, serving only as a check that the packages can be built.

The reason I think it's unfortunate is that when you use it with an import path pattern, the outcome (whether it writes something to the current working directory or not) might be hard to predict without knowing how many packages the import path pattern will match.

I'll let people more familiar with cmd/go see if there's already another issue tracking this (I looked here briefly and didn't spot one), and if anything more can or should be done.

/cc @jayconrod @bcmills @matloob

@dmitshur dmitshur changed the title go build ./... does not generate executable binary cmd/go: go build ./... may or may not generate executable binary depending how many packages the import path pattern matches Jun 12, 2020
@dmitshur dmitshur changed the title cmd/go: go build ./... may or may not generate executable binary depending how many packages the import path pattern matches cmd/go: go build ./... may or may not write executable to disk depending how many packages the import path pattern matches Jun 12, 2020
@dmitshur dmitshur added GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jun 12, 2020
@dmitshur dmitshur added this to the Backlog milestone Jun 12, 2020
@bcmills
Copy link
Contributor

bcmills commented Jun 12, 2020

As of Go 1.13, you can pass -o . to explicitly request output of multiple binaries (see https://golang.org/doc/go1.13#go-command, and design discussion on #14295).

For the sake of consistency, it is unfortunate that we do write the binary when the pattern happens to match only one package, but I'm not sure how feasible that would be to change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
3 participants
@dmitshur @bcmills @xyzst