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

Jump to bottom

cmd/link: -ldflags -X does not work for all import paths #16710

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

cmd/link: -ldflags -X does not work for all import paths #16710

iaburton opened this issue Aug 15, 2016 · 8 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.8

Comments

@iaburton
Copy link

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
Copy link
Contributor

Probably just a bug.

@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 7, 2016
@quentinmit
Copy link
Contributor

@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
Copy link
Author

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
Copy link
Contributor

rsc commented Oct 25, 2016 •
edited

@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
Copy link
Contributor

rsc commented Oct 25, 2016

Sorry, wrong mention: @iaburton.

@gopherbot
Copy link

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

@iaburton
Copy link
Author

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

@gopherbot
Copy link

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

gopherbot pushed a commit that referenced this issue Jan 2, 2017
@ianlancetaylor
cmd/link: don't suggest using nm to find -X name
f78cd56 
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>
@ianlancetaylor ianlancetaylor mentioned this issue Aug 25, 2017
Closed
@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.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.8
Development

No branches or pull requests
6 participants
@bradfitz @rsc @rakyll @quentinmit @iaburton @gopherbot