cmd/go: -ldflags -X does not cause binary to be rebuilt #18369
Comments
josharian
changed the title
|
A workaround is to use go install -a.
The general problem is how could cmd/go detect whether it's necessary
to rebuild a program if only -gcflags and -ldflags is changed on command
line? Currently, cmd/go doesn't record the used gcflags and ldflags in
a binary. Recording gcflags and ldflags in all packages and binaries will
result in excessive rebuilds.
|
|
@minux Honest question: why are you concerned about excessive rebuilds? Do you think that people often build with different -gcflags and/or -ldflags and do not expect the specified programs to be rebuilt? I think this would be easy enough to fix by adding -gcflags and -ldflags to the build ID, but, of course, we should make sure that is the right thing to do. |
|
CL https://golang.org/cl/37384 mentions this issue. |
|
CL https://golang.org/cl/37385 mentions this issue. |
When set to false, the -dolinkobj flag instructs the compiler not to generate or emit linker information. This is handy when you need the compiler's export data, e.g. for use with go/importer, but you want to avoid the cost of full compilation. This must be used with care, since the resulting files are unusable for linking. This CL interacts with #18369, where adding gcflags and ldflags to buildid has been mooted. On the one hand, adding gcflags would make safe use of this flag easier, since if the full object files were needed, a simple 'go install' would fix it. On the other hand, this would mean that 'go install -gcflags=-dolinkobj=false' would rebuild the object files, although any existing object files would probably suffice. Change-Id: I8dc75ab5a40095c785c1a4d2260aeb63c4d10f73 Reviewed-on: https://go-review.googlesource.com/37384 Run-TryBot: Josh Bleecher Snyder <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]>
When running on the host platform, the standard library has almost certainly already been built. However, all other platforms will probably need building. Use the new -dolinkobj=false flag to cmd/compile to only build the export data instead of doing a full compile. Having partial object files could be confusing for people doing subsequent cross-compiles, depending on what happens with #18369. However, cmd/vet/all will mainly be run by builders and core developers, who are probably fairly well-placed to handle any such confusion. This reduces the time on my machine for a cold run of 'go run main.go -all' by almost half: benchmark old ns/op new ns/op delta BenchmarkVetAll 240670814551 130784517074 -45.66% Change-Id: Ieb866ffb2cb714b361b0a6104077652f8eacd166 Reviewed-on: https://go-review.googlesource.com/37385 Run-TryBot: Josh Bleecher Snyder <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]> Reviewed-by: Rob Pike <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>
|
Work on better caching will fix this. I have a prototype. Not for Go 1.9 but probably for Go 1.10. |
|
I ran into this while adding versions to a cli tool. The best workaround I found was to run Looking forward to removing that workaround in Go 1.10 though. One solution I previously tried was to put the version details in a I thought the first |
|
Change https://golang.org/cl/73212 mentions this issue: |
basically go install doesn't properly apply ldflags="-X ..." if nothing within the code has changed. I expected it to properly apply the -X values regardless.
This was very unexpected for me and caused a bit of confusion given if I had a previously built binary without flags and then tried with flags nothing happened.
related to #18246
What version of Go are you using (
go version)?go version go1.7.3 linux/amd64
What operating system and processor architecture are you using (
go env)?What did you do?
What did you expect to see?
What did you see instead?
Work around
output from go tool nm:
The text was updated successfully, but these errors were encountered: