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: build -ldflags="-s -w"
invalid
#25046
Comments
Can you please repeat the experiment with
go build -x -ldflags="-s -w"
…On 24 April 2018 at 12:15, zan ***@***.***> wrote:
What version of Go are you using (go version)?
go version go1.10.1 windows/amd64
Does this issue reproduce with the latest release? What operating system
and processor architecture are you using (go env)?
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=d:\GoLang\go.ext
set GORACE=
set GOROOT=d:\GoLang\go1.10.1
set GOTMPDIR=
set GOTOOLDIR=d:\GoLang\go1.10.1\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 -fmessage-length=0
-fdebug-prefix-map=B:\TEMP\go-build911831290=/tmp/go-build
-gno-record-gcc-switches
What did you do?
go source path: D:\GoLang\go.ext\src\github.com\gooid\demo\main.go
package main
import (
"fmt"
)
func main() {
fmt.Println("hello")
}
cmd:
d:\GoLang\go.ext\src\github.com\gooid\demo>set GOPATH=d:\GoLang\go.ext
d:\GoLang\go.ext\src\github.com\gooid\demo>go build -ldflags="-s -w"
d:\GoLang\go.ext\src\github.com\gooid\demo>dir demo.exe
...
2018/04/24 10:05 1,259,520 demo.exe
...
d:\GoLang\go.ext\src\github.com\gooid\demo>set GOPATH=D:\GoLang\go.ext
d:\GoLang\go.ext\src\github.com\gooid\demo>go build -ldflags="-s -w"
d:\GoLang\go.ext\src\github.com\gooid\demo>dir demo.exe
...
2018/04/24 10:05 2,051,584 demo.exe
...
d:\GoLang\go.ext\src\github.com\gooid\demo>set GOPATH=d:\golang\go.ext
d:\GoLang\go.ext\src\github.com\gooid\demo>go build -ldflags="-s -w"
d:\GoLang\go.ext\src\github.com\gooid\demo>dir demo.exe
...
2018/04/24 10:06 2,051,584 demo.exe
...
What did you expect to see?
The size of all demo.exe is 1,259,520
What did you see instead?
Different GOPATH (but effective in Window), The size of all demo.exe is
different, -ldflags="-s -w" invalid。
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#25046>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAcA66GLOoHaDvP0BN_sJJwIe2Gw2oWks5trorFgaJpZM4Tg5XM>
.
|
|
Can you also do the dir check to confirm that the size is different between the first and second invocation. |
|
I the first invocation
In the second it is missing
/cc @rsc |
Does it work if you run |
|
I suspect cmd/go breaks on windows when os.Getwd returns path that differs from what %GOPATH% contains just in case of its characters. For example, c:\go and C:\GO - both paths are correct paths on Windows. And they refer to the same directory on Windows. But cmd/go treats them as different directories: I see no way to fix this but to convert these paths to upper case (or lower case) before comparing on windows. Please let me know, if there is a better way. I think this is a dup of #19491 and #24232 Alex |
https://github.com/golang/go/blob/dev.boringcrypto.go1.10/src/cmd/go/internal/load/search.go#L285 maybe :
|
My mistake, that was meant to say that this current issue is a dup of #19491 and #24750
I would not know. Alex |
Change https://golang.org/cl/109235 mentions this issue: |
Change https://golang.org/cl/129059 mentions this issue: |
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>
What version of Go are you using (
go version
)?go version go1.10.1 windows/amd64
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
go env
)?set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=d:\GoLang\go.ext
set GORACE=
set GOROOT=d:\GoLang\go1.10.1
set GOTMPDIR=
set GOTOOLDIR=d:\GoLang\go1.10.1\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 -fmessage-length=0 -fdebug-prefix-map=B:\TEMP\go-build911831290=/tmp/go-build -gno-record-gcc-switches
What did you do?
go source path: D:\GoLang\go.ext\src\github.com\gooid\demo\main.go
cmd:
What did you expect to see?
The size of all demo.exe is 1,259,520
What did you see instead?
Different GOPATH (but effective in Window), The size of all demo.exe is different,
-ldflags="-s -w"
invalid。The text was updated successfully, but these errors were encountered: