14 Sep 2025 |
emily | also, uh | 19:31:45 |
emily | surely it shouldn't be _FOR_TARGET in buildGoModule ? | 19:31:54 |
emily | unless Go's splicing is just completely screwy? | 19:32:11 |
emily | doesn't that imply every dependency of a cross Go package will be spliced wrong… | 19:32:27 |
Lun | nope. https://github.com/NixOS/nixpkgs/pull/442965 is the current state, I don't think I have enough of an understanding of how cross to reason about what is going on as demonstrated above by looking at the wrong .go package | 19:34:40 |
Lun | * nope. https://github.com/NixOS/nixpkgs/pull/442965 is the current state, I don't think I have enough of an understanding of how cross should be to reason about what is going on as demonstrated above by looking at the wrong .go package | 19:35:06 |
| jbow joined the room. | 20:17:13 |
emily | oh sorry | 20:17:59 |
emily | by "now" I mean on master | 20:18:02 |
emily | it sounded like the kind of thing that might just, already be broken | 20:18:09 |
emily | pkgsCross.aarch64-multiplatform.go is a Go compiler that runs on aarch64-linux and produces executables for aarch64-linux | 20:18:27 |
emily | pkgsCross.aarch64-multiplatform.buildPackages.go is a Go compiler that runs on (your build platform) and produces executables for aarch64-linux | 20:18:39 |
emily | usually you want buildPackages. for a compiler, when doing cross. pkgsCross.aarch64-multiplatform.foo will have go in its nativeBuildInputs giving you buildPackages.go | 20:19:01 |
Lun | ah, pkgsCross.aarch64-multiplatform.go does build there | 20:21:39 |
emily | gotcha, ok | 20:21:46 |
emily | so I think what's happening now is that the intermediate build results aren't PIE etc., so they are static, no linker | 20:22:05 |
emily | and if they were -linkmode=external they would be using FHS paths already and breaking | 20:22:14 |
emily | *no loader | 20:22:32 |
emily | so we're in an awkward situation where it's now caring about the dynamic loader for the intermediate builds and we have no way to tell it a value that'll work for all of them | 20:22:41 |
emily | hmmmmmmm | 20:23:58 |
emily | I'm thinking of simple fixes but also they have CC_FOR_${GOOS}_${GOARCH} I wonder if we can just convince them to GO_LDSO_FOR_… | 20:26:00 |
emily | https://github.com/golang/go/blob/ac803b5949f6dbc5bfa559afe506d35f9e1b3195/src/cmd/dist/build.go#L281 | 20:26:16 |
emily | this is annoyingly not part of go(1) itself… | 20:26:33 |
emily | Lun: shot in the dark, but BOOT_GO_GCFLAGS=-buildmode=exe …? | 20:28:28 |
emily | sorry this has been a pain. will think more about what would be simple + good to do here | 20:30:29 |
emily | ummmm. pkgs/by-name/ms/msgpack is pkgs/by-name/ms/msgpack-cxx except years old | 20:39:53 |
emily | wonderful | 20:39:54 |
Lun | In reply to @emilazy:matrix.org Lun: shot in the dark, but BOOT_GO_GCFLAGS=-buildmode=exe …? will give it a try when i'm next at my pc idea is we force it to make a static bootstrap go again so LDSO doesn't matter? | 20:41:19 |
emily | right. or something. | 20:42:52 |
emily | it's not clear to me exactly what stage is getting broken | 20:42:58 |