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

laboger opened this issue Aug 11, 2016 · 2 comments

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

laboger opened this issue Aug 11, 2016 · 2 comments


Copy link

@laboger 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 is best.
    Simple testcase:
    package main

import (

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:
    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.
Copy link

@mwhudson mwhudson commented Aug 11, 2016

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?)

Copy link

@gopherbot gopherbot commented Aug 11, 2016

CL mentions this issue.

@quentinmit quentinmit added this to the Go1.8 milestone Aug 15, 2016
@gopherbot gopherbot closed this in b5e43e6 Aug 16, 2016
ceseo added 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
Run-TryBot: Michael Hudson-Doyle <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: David Crawshaw <>
@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.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.