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/compile: compiler variable folding can break linker's -X option #24890
Comments
As far as I can tell, a big part of the confusion is that -X will blindly succeed, whether such a variable exists or not. If it errored out, diagnosing things might be confusing, but at least you'd know.. Longer term, I feel like we'd be better off with a way of overriding constants not variables (and likely at package build time, not at link time). |
At least at first glance this does look like a compiler optimization. I'm not sure what to do about this. It seems a shame to disable a useful compiler optimization for the extremely rare case of using the linker's |
In the original example the initialization of |
The reasonable workaround to the OP's problem is to wrap any use of a variable which might be
|
Here's a version of the issue that is closer to the actual truth:
The way I worked around the issue now was to move the command initialization into the body of a function. For example this will yield the correct result:
Perhaps you know of a more suitable way of setting the version other than using -X though? |
You could use build tags. |
I'm facing a problem when I'm trying to set a variable at build time using the LDFLAG -X. The issue seem to occur because the compiler optimizes the variable into a constant since it's not being used in the package.
Here's a very simplfied code snippet that shows the issue:
If you change the
bar
variable initialization line to:var bar = foo + ""
the output is as expected:go version go1.10.1 linux/amd64
The text was updated successfully, but these errors were encountered: