| 3 Jul 2025 |
 jsnf | * Suppose you are packaging a go project that uses go version 1.24.4 ( declared in the go.mod)
Would you use BuildGoModule or BuildGo124Module?
The project will upgrade go versions according to new releases | 12:56:33 |
| jsnf | * Suppose you are packaging a go project that uses go version 1.24.4 ( declared in the go.mod)
Would you use BuildGoModule or BuildGo124Module?
The project will upgrade go versions according to new releases | 12:56:45 |
| jsnf | Its for nixpkgs | 12:57:27 |
 jrick | dunno the nixpkgs policy but i would only specify the version if the current version was too low | 12:57:35 |
| jsnf | So according to which go version is used in the latest release or unstable channel? | 12:58:45 |
| jrick | or maybe even patch the go.mod version... | 12:59:27 |
| jrick | i don't know if there are any hard rules about how to deal with it, but i'm sure the reviewers will give their opinions | 13:00:45 |
| jsnf | Sadly cant do that as its not my project but something im packaging for others haha | 13:00:52 |
| jsnf | Yeaa | 13:01:01 |
| jsnf | Thank you tho, preciate your help | 13:01:15 |
 Paul Meyer (katexochen) | policy documented here: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/go/README.md | 14:15:03 |
| Paul Meyer (katexochen) | you should use buildGoModule where ever possible (with some minor exceptions) | 14:15:34 |
| Paul Meyer (katexochen) | Shouldn't be a problem to substitute the go/toolchain version in go.mod from x.x.x to x.x.0 if needed. | 14:16:59 |
| Paul Meyer (katexochen) | There is also a section in the manual on versioned builders: https://nixos.org/manual/nixpkgs/unstable/#ssec-go-toolchain-versions | 14:18:38 |
| 5 Jul 2025 |
| jsnf | Ahhh got it, thank you so much! | 15:39:19 |
| 10 Jul 2025 |
|  @aerunakai:matrix.org joined the room. | 05:46:05 |
 kdn | is there a way to build system-independent Go binaries on NixOS? I'm trying to build an Alpine container that requires passing the binary externally and getting those pesky file not founds | 19:08:33 |
 Curid | why not use a scratch base instead of alpine? | 19:10:47 |
| kdn | could probably design it around scratch some time in the future, but right now I need to create an entrypoint bash script for the app and that's it | 19:12:08 |
| Curid | should be distro independent if you set CGO_ENABLE=0 | 19:14:08 |
| jrick | not necessarily. enabling pie will still use the dynamic loader | 19:16:24 |
| jrick | but you can override the path to the dynamic loader, and force it to use the standard path to the musl one which will work on alpine | 19:17:07 |
| Curid | patchelf --set-interpreter "/lib64/ld-linux-x86-64.so.2" file | 19:17:21 |
| jrick | there's that hack, but also there's a variable you can set in the go tooling | 19:17:38 |
| jrick | don't remember it exactly off top of my head, just that it exists | 19:17:52 |
| jrick | go tool link -extld <path> | 19:19:02 |
| jrick | so, set that with ldflags | 19:19:11 |
 Diamond (it/she) | CGO_ENABLED=0 definitely will work | 20:47:58 |
| Diamond (it/she) | if your binary still has PIE then you have to fix your environment | 20:48:03 |
| Diamond (it/she) | oh this is Nix, perfect! CGO_ENABLED=0 will work | 20:48:39 |
