cmd/go: build/install without package argument doesn't evaluate -ldflags on Windows #24750
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
OS-Windows
Milestone
Comments
|
Are you positive that you were running the right binary in both cases? I cannot reproduce this with 1.10.1 on Linux. |
mvdan
added
WaitingForInfo
mvdan
changed the title
|
@mvdan As stated this happened on 1.10 Windows. I didn't try Linux. I did try the syntax with a .go program unit instead of a package name, this worked as expected. |
|
Oh and I tried some other flags (like "-s -w"). These too didn't have any effect. |
|
Thanks. For now I'm going to assume that this has something to do with Windows, and wait for someone to try to reproduce the issue on a similar environment. If you have more information to share, please do. |
mvdan
added
OS-Windows
and removed
WaitingForInfo
mvdan
changed the title
|
Yes. I think this is broken. Alex |
|
Works fine for me with current development version: |
|
@fkollmann does not work for me for bbfae46 I do not know what is different between your system and mine. Alex |
|
@alexbrainman that's odd, I reconfirmed that it's working for me. To get the obvious out of the way, I also confirmed it does not depend on the path, or GOROOT or GOPATH being set. It also does not depend on whether cmd or powershell is being used. So I guess the difference has to be at the compile time of go.exe (read: how go was built). This is, what I did using Powershell: git clone https://github.com/golang/go.git go-source-24750
cd .\go-source-24750\
git checkout bbfae469a1d207a415dd813d799df1ed2dd2d80a
$env:GOROOT_BOOTSTRAP="C:\Go\" ; $env:CGO_ENABLED="0" ; $env:GOPATH=$PWD.Path ; $env:GOBIN="$env:GOPATH\bin" ; $env:GOROOT=$env:GOPATH
.\all.batI get the following result: $env:GOROOT="C:\Projekte\go-source-24750\"
& "$env:GOROOT\bin\go.exe" build -ldflags="-X main.version=0.0.1" -o a.exe
.\a.exe
version: 0.0.1
& "$env:GOROOT\bin\go.exe" version
go version devel +bbfae469a1 Sat Apr 7 21:01:07 2018 +0000 windows/amd64 |
|
@fkollmann I do not know why it works for you. Here is my environment: set MYHOME=c:\users\alex\zzz
set GOROOT=%MYHOME%\go
set GOROOT_BOOTSTRAP=%MYHOME%\go1.4.3
set GOPATH=%MYHOME%
set MINGW=%MYHOME%\mingw
set PATH=%PATH%;%MINGW%\bin;%GOROOT%\bin
cd %GOROOT%\src
cmdAlex |
|
I have the same issue with Go 1.10.1 on Macos. Thanks to the OP report that it has to do with package argument I am able to build again, so I am very happy. It seems that -ldflags isn't being passed to link. In my case, I was trying to build using a relative package name The package named there is nested rather deeply in my homedir for mono repo reasons and so I symlink a dir, s, in my homedir to src/checkout/go/src/g/s/. This is related. I do not experience the problem if my cwd is $HOME/src/checkout/go/src/g/s/ but I do experience the problem if my cwd is $HOME/s/ Here is an example of the seg fault output. I'm trimming the package file output as it does not seem relevant: If I use a slightly different, but should be equivalent package name: |
|
Change https://golang.org/cl/109235 mentions this issue: |
|
Change https://golang.org/cl/129059 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Aug 17, 2018
A flag setting like -gcflags=-e applies only to the packages named on the command line, not to their dependencies. The way we used to implement this was to remember the command line arguments, reinterpret them as pattern matches instead of package argument generators (globs), and apply them during package load. The reason for this complexity was to address a command-line like: go build -gcflags=-e fmt runtime The load of fmt will load dependencies, including runtime, and the load of runtime will reuse the result of the earlier load. Because we were computing the effective -gcflags for each package during the load, we had to have a way to tell, when encountering runtime during the load of fmt, that runtime had been named on the command line, even though we hadn't gotten that far. That would be easy if the only possible arguments were import paths, but we also need to handle go build -gcflags=-e fmt runt... go build -gcflags=-e fmt $GOROOT/src/runtime go build -gcflags=-e fmt $GOROOT/src/runt... and so on. The match predicates usually did their job well, but not always. In particular, thanks to symlinks and case-insensitive file systems and unusual ways to spell file paths, it's always been possible in various corner cases to give an argument that evalutes to the runtime package during loading but failed to match it when reused to determine "was this package named on the command line?" CL 109235 fixed one instance of this problem by making a directory pattern match case-insensitive on Windows, but that is incorrect in some other cases and doesn't address the root problem, namely that there will probably always be odd corner cases where pattern matching and pattern globbing are not exactly aligned. This CL eliminates the assumption that pattern matching and pattern globbing are always completely in agreement, by simply marking the packages named on the command line after the package load returns them. This means delaying the computation of tool flags until after the load too, for a few different ways packages are loaded. The different load entry points add some complexity, which is why the original approach seemed more attractive, but the original approach had complexity that we simply didn't recognize at the time. This CL then rolls back the CL 109235 pattern-matching change, but it keeps the test introduced in that CL. That test still passes. In addition to fixing ambiguity due to case-sensitive file systems, this new approach also very likely fixes various ambiguities that might arise from abuse of symbolic links. Fixes #24232. Fixes #24456. Fixes #24750. Fixes #25046. Fixes #25878. Change-Id: I0b09825785dfb5112fb11494cff8527ebf57966f Reviewed-on: https://go-review.googlesource.com/129059 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?go version go1.10 windows/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Roland\AppData\Local\go-build
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=d:\dvlp\go
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\Roland\AppData\Local\Temp\go-build158086470=/tmp/go-build -gno-record-gcc-switches
What did you do?
In GOPATH\src\hello\main,go:
What did you expect to see?
version to have the ldflags supplied value.
What did you see instead?
Build without package specified did not replace version value. (Same difference when using go install).
The text was updated successfully, but these errors were encountered: