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/link: -ldflags -X option does not work with -linkshared #16671

Closed
laboger opened this issue Aug 11, 2016 · 2 comments
Closed

cmd/link: -ldflags -X option does not work with -linkshared #16671

laboger opened this issue Aug 11, 2016 · 2 comments
Milestone

Comments

@laboger
Copy link
Contributor

laboger commented Aug 11, 2016

Please answer these questions before submitting your issue. Thanks!

  1. What version of Go are you using (go version)?
    go version devel +748aa84 Wed Aug 10 20:33:11 2016 +0000 linux/ppc64le
  2. What operating system and processor architecture are you using (go env)?
    ppc64le Ubuntu 16.04
  3. What did you do?
    If possible, provide a recipe for reproducing the error.
    A complete runnable program is good.
    A link on play.golang.org is best.
    Simple testcase:
    test-setX.go:
    package main

import (
"fmt"
)

var VERSION string

func main() {
fmt.Printf("Hello, World! Version is: %s\n", VERSION)
}
Make sure there is a shared std libary
go install -buildmode=shared std
go build -linkshared -ldflags '-X main.VERSION=123' test-setX.go

  1. What did you expect to see?
    Successful build and execution. Output without -linkshared is:
    ./test-setX
    Hello, World! Version is: 123
  2. What did you see instead?
    Program didn't build, error message was:
    cannot use -X with non-string symbol main.VERSION type.TwVfYA92
    (I modified src/cmd/link/internal/ld/data.go to print out the actual type at the end of the message. That does not appear by default.)
    I also just tried removing the test in data.go where this error message occurs, and then the program built successfully but panicked at runtime.
@mwhudson
Copy link
Contributor

Pretty sure that type.TwVfYA92 is actually type.string, type symbols get their names compressed (in general, it's actually getting expanded here). A fix would be to not mangle type names when the mangling would in fact make the names longer (@crawshaw?)

@gopherbot
Copy link

CL https://golang.org/cl/26890 mentions this issue.

@quentinmit quentinmit added this to the Go1.8 milestone Aug 15, 2016
ceseo pushed a commit to powertechpreview/go that referenced this issue Aug 16, 2016
When dynamically linking, a type symbol's name is replaced with a name based on
the SHA1 of the name as type symbol's names can be very long.  However, this
can make a type's symbol name longer in some cases. So skip it in that case.
One of the symbols this changes the treatment of is 'type.string' and that fixes a
bug where -X doesn't work when dynamically linking.

Fixes golang#16671

Change-Id: If5269038261b76fb0ec52e25a9c1d64129631e3c
Reviewed-on: https://go-review.googlesource.com/26890
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
@golang golang locked and limited conversation to collaborators Aug 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants