Skip to content
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: invalid -ldflags is silently ignored #43177

hyangah opened this issue Dec 14, 2020 · 6 comments

cmd/go: invalid -ldflags is silently ignored #43177

hyangah opened this issue Dec 14, 2020 · 6 comments
GoCommand NeedsFix


Copy link

@hyangah hyangah commented Dec 14, 2020

go version go1.15.5 linux/amd64

$ cat main.go
package main
var X = ""
func main() {	println(X)  }

$ go run -ldflags='-X main.X=Hello' main.go
$ go run -ldflags='"-X main.X=Hello"' main.go


The -ldflags of the second go run is in invalid format, but the go command silently ignores it and keeps working.

$ go run -ldflags='"-X main.X=Hello"' -x main.go
mkdir -p $WORK/b001/
mkdir -p $WORK/b001/exe/
cd .
$GOROOT/pkg/tool/linux_amd64/link -o $WORK/b001/exe/main -importcfg $WORK/b001/ -s -w -buildmode=exe -buildid=HYVxxilVrLgdctP3U_YF/h7WWNLZkY13bQM5oqdBD/IUwm0pzLWLHdmcshsYuR/HYVxxilVrLgdctP3U_YF -extld=clang $WORK/b001/_pkg_.a

See above link command. That's missing -X main.X=Hello

Copy link

@bcmills bcmills commented Dec 14, 2020

From what I can tell, that flag is here:

BuildLdflags PerPackageFlag // -ldflags

That triggers the parsing case here:

if !strings.HasPrefix(v, "-") {
i := strings.Index(v, "=")
if i < 0 {
return fmt.Errorf("missing =<value> in <pattern>=<value>")
if i == 0 {
return fmt.Errorf("missing <pattern> in <pattern>=<value>")
pattern := strings.TrimSpace(v[:i])
match = MatchPackage(pattern, cwd)
v = v[i+1:]

...which succeeds because it finds =, and then attempts to match "-X main.X against a package path (which obviously fails to match anything because it's not a syntactically valid package path).

Before we call MatchPackage on the parsed pattern, we should first verify that it is a syntactically valid package pattern.

CC @jayconrod @matloob

@bcmills bcmills added GoCommand NeedsFix labels Dec 14, 2020
@bcmills bcmills added this to the Backlog milestone Dec 14, 2020
Copy link

@gopherbot gopherbot commented Aug 2, 2021

Change mentions this issue: load: fix ldflags invalid parameters

Copy link

@mpictor mpictor commented Aug 17, 2021

Not sure if it's this exact issue, but I just noticed that with go1.16.4 the buildid I set is silently failing, and when it does it wipes out other ldflags.

go build -n -ldflags "'-buildid=my id' -X main.somevar='other value'" -o mybin cmd/go |&tail -n3|head -n1|sed 's/ -/\n -/g'

  -o $WORK/b001/exe/a.out
  -importcfg $WORK/b001/
  -extld=gcc $WORK/b001/_pkg_.a

go build -n -ldflags "-X main.somevar='other value'" -o mybin cmd/go |& tail -n3|head -n1|sed 's/ -/\n -/g'

  -o $WORK/b001/exe/a.out
  -importcfg $WORK/b001/
  -X main.somevar='other value'
  -extld=gcc $WORK/b001/_pkg_.a

In the past I was able to set a build id containing spaces using the syntax in the first command, i.e. '-buildid=some value' - so disallowing build id's containing spaces is a regression.

Copy link

@mpictor mpictor commented Aug 18, 2021

It seems the order of args matters:
go build -n -ldflags "-X main.somevar='other value' '-buildid=my id'" -o mybin cmd/go |&tail -n3|head -n1|sed 's/ -/\n -/g'

  -o $WORK/b001/exe/a.out
  -importcfg $WORK/b001/
  -X main.somevar='other value' "-buildid=my id"
  -extld=gcc /home/mark/.cache/go-build/dc/dc883a0241b3ab0a931f8972d7457b4f52681d8efc982c5537dbef0f34fc766f-d

However, this command results in an error if actualy executed (by removing -r:
go build -ldflags "-X main.somevar='other value' '-buildid=my id'" -o mybin cmd/go

# cmd/go
usage: link [options] main.o
  -B note
        add an ELF NT_GNU_BUILD_ID note when using ELF

Copy link

@gopherbot gopherbot commented May 19, 2022

Change mentions this issue: misc/cgo/testplugin: set the package name in TestIssue19534

gopherbot pushed a commit that referenced this issue May 19, 2022
The fix for #19534 (in CL 40994) adjusted escaping in the
dynamically-linked name lookup logic for the plugin package. However,
the regression test added for it incorrectly included quotes within
the -ldflags flag, causing the flag to inadvertently be ignored.

Possibly in that same CL or possibly at some other point, the
condition that the test thought it was checking stopped working: the
dynamic lookup used the path passed to ldflags, but the object file
actually contained the symbol indexed by the original package name.

Ideally we should stop mucking around with ldflags in this test and
run 'go build' from a suitably-named directory instead, to mimic the
actual conditions in which the original bug was reported. For now, as
a more targeted fix, we can pass the '-p' flag to the compiler to
adjust the package path used at compile time to match the one that
will be set at link time.

For #43177.
Updates #19534.

Change-Id: I9763961feb37cfb05dee543f273492e91a350663
Run-TryBot: Bryan Mills <>
TryBot-Result: Gopher Robot <>
Reviewed-by: Ian Lance Taylor <>
Auto-Submit: Bryan Mills <>
Reviewed-by: Than McIntosh <>
Copy link

@gopherbot gopherbot commented Aug 1, 2022

Change mentions this issue: .github/workflows: add go1.19rc2 to long/smoke tests

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
GoCommand NeedsFix
None yet

No branches or pull requests

4 participants