cmd/go: -ldflags pattern matching broken when building from symlinked pwd #24359

knz · 2018-03-12T20:29:56Z

tl;dr: if the PWD of the current shell is a symlink to a dir in $GOPATH, then linking with -X does not work.

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

go version go1.10 freebsd/amd64

Does this issue reproduce with the latest release?

yes

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/data/home/kena/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="freebsd"
GOOS="freebsd"
GOPATH="/data/home/kena/src/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/freebsd_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
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=/tmp/go-build068611065=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Check the README here: https://github.com/knz/build-x-bug

In short:

make package in $GOPATH. Use go build -ldflags '-X yourpackage/var=val' -> this works
create symlink to package in $GOPATH, in another dir, set that as PWD. Then use same go build command -> this breaks, -X does not set the var.

What did you expect to see?

-X with a package path relative to $GOPATH should work regardless of PWD.

What did you see instead?

Whether -X works properly or not is dependent on the PWD.

Suggested fix.

use filepath.Abs on the PWD before trying to make clever comparisons in the linker.

The text was updated successfully, but these errors were encountered:

knz · 2018-03-12T20:35:41Z

I think that filepath.Abs on the pwd is not sufficient, GOPATH itself must also be normalized with Abs.

knz · 2018-03-12T20:38:03Z

I also think this is a regression with 1.10 - wasn't there in 1.9

andybons · 2018-03-13T17:53:40Z

/cc @ianlancetaylor

ianlancetaylor · 2018-03-13T22:09:00Z

It works if you use -ldflags=all='-X ...'.

Perhaps the $PWD referring to a symlink changes the matching of the -ldflags pattern somehow.

ianlancetaylor · 2018-03-13T22:25:17Z

Likely could be fixed by calling filepath.EvalSymlinks in getwd before setting base.Cwd in cmd/go/internal/base.

ysmolski · 2018-03-16T22:12:53Z

@ianlancetaylor I have verified your version and it turns out to be a working fix. Should we have a proper test for it in go_test.go?

ianlancetaylor · 2018-03-16T22:28:04Z

Yes, it ought to have a test.

gopherbot · 2018-03-17T11:27:23Z

Change https://golang.org/cl/101256 mentions this issue: cmd/go: fix -X importpath.name=value when building from symlinked wd

rsc · 2018-04-18T14:02:34Z

I wrote on the CL:

In general, don't use symlinks and expect things to work.
The call to EvalSymlinks will fix this one test case, where evaluating the symlink
makes the path move into GOPATH. But it will break the inverse test case, where
evaluating the symlink makes the path move out of GOPATH.

The answer is to not use symlinks.

I think we should leave the current behavior alone. GOPATH is on its way out anyway.

knz · 2018-04-18T14:41:37Z

In general, don't use symlinks and expect things to work.

It worked in every Go version prior to 1.10. Why break it until GOPATH is out?

ianlancetaylor · 2018-04-18T16:28:02Z

It worked by accident in every prior Go version. I don't feel strongly about this particular issue, but as a general rule we don't want to lock ourselves into behavior that was not documented and that worked by accident.

RaduBerinde · 2018-04-23T18:38:58Z

In general, don't use symlinks and expect things to work.
The call to EvalSymlinks will fix this one test case, where evaluating the symlink
makes the path move into GOPATH. But it will break the inverse test case, where
evaluating the symlink makes the path move out of GOPATH.

The answer is to not use symlinks.

It's reasonable to disallow symlinks in the GOPATH itself. But whether the cwd is a symlink or not shouldn't matter. At least that's my expectation as a user (and it's not something I would expect to be specifically documented).

Build info injected via linker flags, like the Git commit SHA, is dropped on the floor when building from a symlink (e.g., ~/roach -> ~/go/src/cockroachdb/cockroach). This issue was filed upstream (golang/go#24359), but the Go team refused to fix it. Luckily, we can work around it by teaching Make to resolve any symlinks in the CWD. Release note: None

Build info injected via linker flags, like the Git commit SHA, is dropped on the floor when building from a symlink (e.g., ~/roach -> ~/go/src/cockroachdb/cockroach). This issue was filed upstream (golang/go#24359), but the Go team refused to fix it. Luckily, we can work around it by teaching Make to resolve any symlinks in the CWD. Release note (build change): Build metadata, like the commit SHA and build time, is properly injected into the binary when using Go 1.10 and building from a symlink.

25008: Makefile: work around symlink bug in Go toolchain r=knz a=benesch Build info injected via linker flags, like the Git commit SHA, is dropped on the floor when building from a symlink (e.g., ~/roach -> ~/go/src/cockroachdb/cockroach). This issue was filed upstream (golang/go#24359), but the Go team refused to fix it. Luckily, we can work around it by teaching Make to resolve any symlinks in the CWD. Release note (build change): Build metadata, like the commit SHA and build time, is properly injected into the binary when using Go 1.10 and building from a symlink. Co-authored-by: Nikhil Benesch <nikhil.benesch@gmail.com>

Build info injected via linker flags, like the Git commit SHA, is dropped on the floor when building from a symlink (e.g., ~/roach -> ~/go/src/cockroachdb/cockroach). This issue was filed upstream (golang/go#24359), but the Go team refused to fix it. Luckily, we can work around it by teaching Make to resolve any symlinks in the CWD. Release note (build change): Build metadata, like the commit SHA and build time, is properly injected into the binary when using Go 1.10 and building from a symlink.

25062: backport-2.0: Makefile: work around symlink bug in Go toolchain r=knz a=benesch Backport 1/1 commits from #25008. /cc @cockroachdb/release --- Build info injected via linker flags, like the Git commit SHA, is dropped on the floor when building from a symlink (e.g., ~/roach -> ~/go/src/cockroachdb/cockroach). This issue was filed upstream (golang/go#24359), but the Go team refused to fix it. Luckily, we can work around it by teaching Make to resolve any symlinks in the CWD. Release note (build change): Build metadata, like the commit SHA and build time, is properly injected into the binary when using Go 1.10 and building from a symlink. Co-authored-by: Nikhil Benesch <nikhil.benesch@gmail.com>

andybons changed the title ~~tools/link: -X broken when building from symlinked pwd~~ cmd/link: -X broken when building from symlinked pwd Mar 13, 2018

andybons added the NeedsInvestigation label Mar 13, 2018

ianlancetaylor changed the title ~~cmd/link: -X broken when building from symlinked pwd~~ cmd/go: -ldflags pattern matching broken when building from symlinked pwd Mar 13, 2018

ianlancetaylor added NeedsFix help wanted labels Mar 13, 2018

gopherbot removed the NeedsInvestigation label Mar 13, 2018

ianlancetaylor added this to the Go1.11 milestone Mar 13, 2018

rsc closed this as completed Apr 18, 2018

benesch mentioned this issue Apr 23, 2018

Makefile: work around symlink bug in Go toolchain cockroachdb/cockroach#25008

Merged

benesch mentioned this issue Apr 25, 2018

backport-2.0: Makefile: work around symlink bug in Go toolchain cockroachdb/cockroach#25062

Merged

klingerf mentioned this issue May 18, 2018

Build CLI only for host platform linkerd/linkerd2#884

Merged

golang locked and limited conversation to collaborators Apr 23, 2019

gopherbot added the FrozenDueToAge label Apr 23, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: -ldflags pattern matching broken when building from symlinked pwd #24359

cmd/go: -ldflags pattern matching broken when building from symlinked pwd #24359

knz commented Mar 12, 2018

knz commented Mar 12, 2018

knz commented Mar 12, 2018

andybons commented Mar 13, 2018

ianlancetaylor commented Mar 13, 2018

ianlancetaylor commented Mar 13, 2018

ysmolski commented Mar 16, 2018

ianlancetaylor commented Mar 16, 2018

gopherbot commented Mar 17, 2018

rsc commented Apr 18, 2018

knz commented Apr 18, 2018

ianlancetaylor commented Apr 18, 2018

RaduBerinde commented Apr 23, 2018

cmd/go: -ldflags pattern matching broken when building from symlinked pwd #24359

cmd/go: -ldflags pattern matching broken when building from symlinked pwd #24359

Comments

knz commented Mar 12, 2018

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

Does this issue reproduce with the latest release?

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?

Suggested fix.

knz commented Mar 12, 2018

knz commented Mar 12, 2018

andybons commented Mar 13, 2018

ianlancetaylor commented Mar 13, 2018

ianlancetaylor commented Mar 13, 2018

ysmolski commented Mar 16, 2018

ianlancetaylor commented Mar 16, 2018

gopherbot commented Mar 17, 2018

rsc commented Apr 18, 2018

knz commented Apr 18, 2018

ianlancetaylor commented Apr 18, 2018

RaduBerinde commented Apr 23, 2018

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

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