Without digging into the details, my guess is that the linker is changing the initial value of the variable, but for the complex expressions, the compiler has added an init() function which overrides the linker-specified default value. Why it works with some funcs but not others I'd guess comes down to whether the compiler manages to eliminate the function (I'm not sure how complex we get with that) and thus the init function.

cc @golang/compiler

I think it is understood that the ldflags can only overwrite a variable's static init value, not one with dynamic evaluation. I agree that the inconsistency is confusing. Maybe we want to disable some optimizations with string-typed global variables.

I think it is understood that the ldflags can only overwrite a variable's static init value...

Could you point me to the documentation for this please?

What is the preferred pattern for providing a complex computed default value but still permitting builders to override via an ldflag?

https://pkg.go.dev/cmd/link

-X importpath.name=value
	Set the value of the string variable in importpath named name to value.
	This is only effective if the variable is declared in the source code either uninitialized
	or initialized to a constant string expression. -X will not work if the initializer makes
	a function call or refers to other variables.

var (
	Injected = ""
	Version  = func() string {
		if Injected != "" {
			return Injected
		}
		return "some default"
	}()
)

-X will not work if the initializer makes a function call or refers to other variables.

I think this is what @prattmic is referencing above, but it sometimes works for some function, depending on how the compiler does.

Also, it's strange that there's no linker error in this situation. Compare:

package main
import "fmt"

var commit int
func main() {
  fmt.Printf("%d\n", commit)
}

$ go run \
  -a \
  -trimpath \
  -ldflags="-s -w -X main.commit=abcdef1 -extldflags=-static" main.go

# command-line-arguments
❌ main.commit: cannot set with -X: not a var of type string (type:int)

to the function signature:

package main
import "fmt"

var commit = func() string {
  return "123"
}()

func main() {
  fmt.Printf("%d\n", commit)
}

which builds fine.

For the case above, the compiler inlines that function, so it becomes var commit = "123". We should probably disable that inlining for string-typed global variable.

Sorry, I mean even a more complex function that isn't inlined:

var commit = func() string {
  if time.Now().Unix()%3 == 0 {
    return "123"
  }
}()

Building that generates no warnings or errors. It seems odd that we return an error when linking against a non-string type... unless it's a function that returns a string type?

For this, the -X flag is ineffective (as documented). Currently it doesn't emit an error, partly because for the linker this is not much different from

var commit string
func init() {
  if time.Now().Unix()%3 == 0 {
    commit = "123"
  }
}

which is a valid program and the linker should not emit an error in any case. Technically the compiler is able to distinguish between the two and leave some metadata in the object file to inform the linker, but I'm not sure whether this is worth doing.

As documented, the -X flag applies only to string variable. It is an error if -X is applied to a non-string variable. So if the function returns a non-string type, it is not a string variable anymore, which causes the error.

Hi @cherrymui thank you for the reply. I understand from a technical perspective why it's behaving this way, but I'm asking you to look at it from the perspective of the user.

The help text says:

Set the value of the string variable in importpath named name to value.
This is only effective if the variable is declared in the source code either uninitialized
or initialized to a constant string expression. -X will not work if the initializer makes
a function call or refers to other variables.

Specifically,

This is only effective if the variable is declared in the source code either uninitialized or initialized to a constant string expression.

When given a non-string expression, the user is presented an informative error that says "hey, you're doing it wrong." But with the second sentence in the help text,

-X will not work if the initializer makes a function call or refers to other variables.

When given a function expression [that returns a string], the user is provided no error or warning, and it silently goes unused.

I understand why the inconsistency exists across the compiler -> linker, but I'm trying to convey that it's unexpected from the user's perspective.

In the first sentence, "ineffective" means "will throw an error". In the second sentence, "ineffective" means "will be ignored". This seems like a really sharp edge case for users.

If it's not worth feeding this metadata from the compiler -> linker, then I think it's still worth updating the help output to note that this edge case will silently fail.

We should probably disable that inlining for string-typed global variable.

Why?

We should probably disable that inlining for string-typed global variable.
Why?

Because otherwise this will cause confusion: the -ldflags=-X flag will be ineffective for

var X string = noninlineableCall()

but effective for

var X string = inlineableCall()

That is very confusing for the users.

We also already disable optimizations like rewriting

var A = "foo"; var B = A

to

var A = "foo"; var B = "foo"

for string-typed global variables (#34675).