| 14 Sep 2025 |
 emily | um part of the GitHub UI I have never seen before cool | 14:12:48 |
| emily | oh you just patched src/cmd/dist/build.go, ok | 14:14:29 |
| emily | yeah so this seems sensible but I do think that just teaching it about the linker path seems like a good idea. let me meditate on the least awful way of doing that | 14:15:16 |
 Lun | Is there a nice env var we already set that I can teach the part that uses buildcfg.GO_LDSO to grab the right interpreter path from? | 14:15:35 |
| emily | also… | 14:15:39 |
| emily | I'm confused | 14:15:44 |
| emily | it tries to use internal linkmode even with cgo on normal Linux, right? | 14:15:52 |
| emily | why doesn't CGO_ENABLED produce busted executables by default then? | 14:16:03 |
| emily | like I get that it works for static because no interp | 14:16:48 |
| emily | but the cgo external library case? | 14:16:54 |
| emily | fwiw, what we do is $NIX_CC/nix-support/dynamic-linker | 14:17:40 |
| emily | but another option would be: teach it about runtime GO_LDSO too | 14:17:49 |
| emily | and then set that in the hook | 14:17:55 |
| emily | and ofc default it to the one being used at compile-time in the Go build | 14:18:09 |
| emily | that might be more upstreamable | 14:18:18 |
| emily | I'm trying to figure out if that part of the code looks at any environment variables or if we'd have to pipe it in | 14:18:32 |
| Lun | It seems like it uses the external linker right now by default in x86_64-linux, I see GCC: (GNU) 14.3.0 in .comment in github:nixos/nixpkgs/nixos-unstable#syncthing | 14:19:04 |
| emily | btw I've been really good at not saying this but I've spent long enough on this now that I have to let off some pressure by saying that I don't really like Go and I think it's kind of bad. | 14:19:15 |
| emily | I keep wondering where this cfg variable is being passed. it's going to be a global variable isn't it | 14:21:00 |
| emily | https://github.com/golang/go/blob/ac803b5949f6dbc5bfa559afe506d35f9e1b3195/src/cmd/go/internal/cfg/cfg.go oh it's a package containing global variables | 14:21:13 |
| emily | okay I think that the linker doesn't have cfg.BuildContext because it's not part of go(1) | 14:22:41 |
| emily | if buildcfg.GOARCH != arch.Name {
log.Fatalf("invalid buildcfg.GOARCH %s (want %s)", buildcfg.GOARCH, arch.Name)
}
| 14:23:17 |
| emily | wait is the linker single-target? | 14:23:20 |
| emily | oh it probably is because it's like the Plan 9 6l 8l stuff | 14:23:28 |
| emily | * For x86, Apple has reserved a slot in the TLS for Go. See issue 23617.
| 14:23:46 |
| emily | need this kind of leverage with Apple | 14:23:55 |
| emily | basically my fear is that this linker doesn't look at any env variables | 14:24:27 |
| emily | and that they'll be like | 14:24:29 |
| emily | no this should be an actual flag and go(1) should pass it down | 14:24:34 |
| emily | and that would be maddening | 14:24:40 |
