17

I'm running into a bizarre problem at work.

I have a project. In this project are two packages, each in its own folder. Each folder contains various .go files that are part of that package.

In folder A, if I say go build -v, I get a list of the stuff it's building.

In folder B, if I say go build -v, I get an immediate return with no output.

Both folders contain nothing but .go files, and there is no easily-identifiable reason why it is building the code in the one and building nothing in the other.

go version returns go version go1.7.5 linux/amd64

How in the world do I figure out what's going on here?

EDIT: To clarify issues brought up in comments:

There is no package main in either folder. In the folder A, go install produces a .a file in the appropriate place under $GOPATH/pkg. In folder B, go install does not. It is doing nothing, and failing silently. Something is legitimately going wrong here.

Suggested remedies from comments include using the -a flag (errors out on something that appears to be completely unrelated) and using the -x flag. The -x flag, which supposedly should give extremely verbose output, instead is useless, outputting single lines referring to temp files that do not exist once the build terminates, such as WORK=/tmp/go-build026498757.

Mason Wheeler
  • 82,511
  • 50
  • 270
  • 477
  • And yes, I have seen https://stackoverflow.com/questions/31144153/go-build-does-not-generate-file-in-golang. It does not address this issue. That was about the build process not producing a binary; this is about the compiler not compiling the files in the current directory *at all*. – Mason Wheeler Feb 02 '18 at 21:23
  • 2
    Also: https://stackoverflow.com/questions/30612611/what-does-go-build-build – JimB Feb 02 '18 at 21:23
  • 2
    If there's no `main` package, there's nothing to build. Can you show some example source? (also, you should update Go to a supported version) – JimB Feb 02 '18 at 21:25
  • @JimB The `-v` switch means it reports what files it's compiling. It outputs *nothing*. This means it doesn't even know whether or not there is a `main` package. – Mason Wheeler Feb 02 '18 at 21:27
  • 1
    No, `-v` reports _when_ it compiles something, not when it actually reads the package files. If there's no `main` package, and the package (and dependencies) have already been installed, then there's nothing to do. – JimB Feb 02 '18 at 21:29
  • @JimB Also, there is no file marked `package main` in the folder in which everything is working properly. I just checked. – Mason Wheeler Feb 02 '18 at 21:30
  • @JimB In that case, `go install -v` should report that it's doing something. It likewise does nothing at all in this case. Something is legitimately wrong here; I'm trying to figure out what. – Mason Wheeler Feb 02 '18 at 21:31
  • 2
    This is the expected behavior. Go build doesn't report every file it reads, just when it compiles things. You probably want `go install`, though that's not going to output anything either without `-a` if the binary artifacts are current. – JimB Feb 02 '18 at 21:32
  • The linked question covers this extensively, and also has a new answer covering the go1.10+ build cache. – JimB Feb 02 '18 at 21:40
  • @JimB I already read that post. **It does not apply here.** There is a legitimate problem. `go install` is not working either; it silently does nothing, fails to report any error, and does not place any output in the appropriate place under `pkg`. (There is also not any earlier output there.) I've noted this in an edit; please reopen the question. – Mason Wheeler Feb 02 '18 at 22:00
  • What does `go install -v -a` output? – JimB Feb 02 '18 at 22:02
  • @JimB OK, *that* finally gets a response: `runtime/internal/sys` \ `go install runtime/internal/sys: open /usr/local/go/pkg/linux_amd64/runtime/internal/sys.a: permission denied` – Mason Wheeler Feb 02 '18 at 22:05
  • If you want to see all build steps, you can add `-x` too. See `go help build` – JimB Feb 02 '18 at 22:06
  • @JimB `go install -x` gives nothing useful; it only responds with a single line: `WORK=`. Attempts to look at this temp file, in case it's a log of the build work, fail; the file doesn't appear to exist after the `go install` finishes. The temp filename is different with every run. – Mason Wheeler Feb 02 '18 at 22:18
  • `-x` will show the exact command that failed, but you need to add `-a` to force it to build everything. – JimB Feb 02 '18 at 22:37
  • @JimB Again, the `-a` flag errors out on attempting to install a system package because it ignores *all* caches, producing an irrelevant error. – Mason Wheeler Feb 02 '18 at 22:38
  • Oh, I thought your error indicated simply that go couldn't _read_ `/usr/local/go/pkg/linux_amd64/runtime/internal/sys.a`, and you had solved it. Where is folder B, and what is in it? Does it have any build constraints? Is it in the GOPATH? Are the files properly named? Can you import the package from B in a `main` package? – JimB Feb 02 '18 at 22:42
  • @JimB Folder B is right alongside Folder A (where everything works) and there is nothing in it except a couple `.go` files (just like in Folder A, where everything works). It is under the GOPATH, all files are properly named, and where would the build constraints even be coming from? – Mason Wheeler Feb 02 '18 at 22:54
  • build constraints are by file name (`*_test.go`, `*_windows.go` `*_amd64.go`, etc), or in the source as `// +build ...`. Files starting with `_` are ignored. Are any of the directories symlinks? Can you successfully import the package? – JimB Feb 02 '18 at 23:00
  • @JimB OK, there's nothing like that in there. And... how would I even try to import the package when I *can't even build it?!?* – Mason Wheeler Feb 02 '18 at 23:00
  • Make a `main` package and try to import it, go will build all dependencies as needed. I'm asking, because if it can't locate the package source, it may provide you with a helpful error as to why your setup isn't working. – JimB Feb 02 '18 at 23:02
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/164440/discussion-between-jimb-and-mason-wheeler). – JimB Feb 02 '18 at 23:22
  • Does mannually adding filenames to the command work? Can you `go build *.go`? – leaf bebop Feb 03 '18 at 01:47

4 Answers4

2

You mention that the temporary directories are gone after the build terminates.

You can retain these directories with the -work flag.

From go help build:

The build flags are shared by the build, clean, get, install, list, run, and test commands:

...

    -work
            print the name of the temporary work directory and
            do not delete it when exiting.

This should help provide some more information and context around what is and is not happening.

jlucktay
  • 390
  • 1
  • 7
  • 23
2

I also faced a similar issue, don't know the root cause but run

go build main.go

Basically, add the filename and try.

Piyush Sinha
  • 21
  • 2
0

It's likely that you already have an up-to-date build installed in your gopath. This might mean that you did something like ran go install on that particular package previously and have yet to modify any of the files in the directory.

Check Go's pkg directory for the corresponding *.a library and see if the modification timestamp on it is later than the timestamps on your source files.

photoionized
  • 5,092
  • 20
  • 23
0

I think go build's result is hiding by your editor.(file tree)

In my case, I am using vscode.
vscode hides files that first char is '.'
if you move to src directory and type ls -al in terminal

Minwoo Yu
  • 360
  • 2
  • 13