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 does not work for all import paths #16710

Closed
iaburton opened this issue Aug 15, 2016 · 8 comments

Comments

Projects
None yet
6 participants
@iaburton
Copy link

commented Aug 15, 2016

Please answer these questions before submitting your issue. Thanks!

  1. What version of Go are you using (go version)?
    go1.6.2
  2. What operating system and processor architecture are you using (go env)?
    linux/amd64
  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.

A program and import similar to these.
Import: https://play.golang.org/p/n_t6GPt_9r
Program/main: https://play.golang.org/p/t9IloQX9Wj
And using -ldflags "-X my/pkg.git.Version=1.0"

  1. What did you expect to see?
    1.0
  2. What did you see instead?
    notset

It seems that any import path ending with a dot before the variable name cannot be found by the linker and set using -X. .git in the import path is valid and is the only way to force 'go get' to use git+ssh afaik. I also tried my/pkg.Version and pkg.Version to the -X argument, but the only thing that fixes it is not having .git in the path (renaming the folder to not contain .git, but then this breaks go get). Is this a bug, or is there a workaround for this? I tried looking for similar issues before filing, thanks.

@rakyll rakyll added this to the Go1.8 milestone Aug 16, 2016

@bradfitz

This comment has been minimized.

Copy link
Member

commented Aug 16, 2016

Probably just a bug.

@quentinmit quentinmit added the NeedsFix label Oct 7, 2016

@quentinmit

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2016

@iaburton I believe you can work around this by renaming the directory to not have .git in the path and put an HTML page there with a meta tag pointing at the .git repo:

https://golang.org/cmd/go/#hdr-Remote_import_paths

@iaburton

This comment has been minimized.

Copy link
Author

commented Oct 12, 2016

Hello @quentinmit, I'm a little confused as to your suggestion. I know renaming the directory to not contain .git will fix the linker issue, but it breaks the import path in all Go files that import it. Having read the link you refer to, a few times, it seems my use case should already work? The code is hosted on a gogs instance which I believe serves content with the meta tag information Go looks for, but I'm not sure if that works over git+ssh which is what I'm using. Although I just remembered in my git config I have it set to use user@domain.com instead of https://domain.com. I think this was to force git+ssh with a specific user. I'm not sure if that factors into this issue

@rsc

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2016

@iaburton, sorry for the delay in answering your question. The rule is that dot after the final slash in an import path gets escaped to %2e when constructing the actual symbol that cmd/link works on. The -X processing should have applied this transformation itself, but it does not. We will fix that for Go 1.8.

There are two workarounds until Go 1.8 is available:

  1. Put the code in a subdirectory of the repo, so that the ".git" is before a slash. In that case, everything will just work.
  2. Replace a trailing .git in the import path with %2egit when preparing the -X argument. In your example, -X my/pkg%2egit.Version=1.0 will work. Note that because Go 1.8 will apply escaping rules, this will stop working in Go 1.8. You can use multiple arguments, though, to handle both cases: -X my/pkg.git.Version=1.0 -X my/pkg%2egit.Version=1.0. The one that doesn't work will just be ignored.

The fix is at https://golang.org/cl/31970.

Edit: fixed @ mention.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2016

Sorry, wrong mention: @iaburton.

@gopherbot

This comment has been minimized.

Copy link

commented Oct 25, 2016

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

@iaburton

This comment has been minimized.

Copy link
Author

commented Oct 25, 2016

Thank you @rsc, those workarounds will do until Go1.8 arrives 😃

@gopherbot gopherbot closed this in 1773cdd Oct 29, 2016

@gopherbot

This comment has been minimized.

Copy link

commented Jan 2, 2017

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

gopherbot pushed a commit that referenced this issue Jan 2, 2017

cmd/link: don't suggest using nm to find -X name
It doesn't work if the package name includes a '.' or a non-ASCII
character (or '%', '"', or a control character).  See #16710 and CL 31970.

Update #18246.

Change-Id: I1487f462a3dc7b0016fce3aa1ea6239b226e6e39
Reviewed-on: https://go-review.googlesource.com/34791
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

@golang golang locked and limited conversation to collaborators Jan 2, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.