| 22 Jun 2026 |
 flumffy | Alyssa Ross: Is using an older version of LLVM an acceptable solution for the OpenBSD stdenv? (I've done more work on getting cross-compilation to work; binaries built with LLVM 19 and newer will run without any patches since upstream fixed the linker issue, though LLVM 21 results in a miscompilation in libc for reasons I don't understand yet.) | 21:16:30 |
| 23 Jun 2026 |
 emily | FWIW Apple ships a pretty divergent LLVM and we just use a vanilla LLVM on Darwin and it's fine | 01:01:14 |
| emily | (though not all of Apple's changes are FOSS so we don't have that much choice) | 01:01:31 |
| emily | we used to have a lot of platform-specific default LLVM versions but equalized them a while back | 01:01:56 |
| emily | it would be unfortunate to reintroduce them | 01:02:13 |
| emily | if OpenBSD doesn't care about LLVM upstream and LLVM upstream doesn't care about OpenBSD that's a systemic problem that is going to hurt for providing OpenBSD support in Nixpkgs tbh :/ | 01:02:50 |
| emily | is this related to the license change stuff? | 01:03:28 |
| flumffy | When I initially started the work on getting OpenBSD to play nicely with cross compiling it was when nixpkgs was still using LLVM 18 (which didn't support the various changes to required sections that OpenBSD had introduced). It seems this isn't an issue nowadays, so we can elide effectively all of the patches I was concerned about manually reviewing/maintaining. | 01:21:44 |
| flumffy | I don't imagine upstream LLVM particularly cares for some of OpenBSD's patches (retguard, cleaning return address off the stack, etc). It's easy enough to remove the few references to these from the OpenBSD sources that are required (-fret-clean is only used in ld.so and libc currently). | 01:23:24 |
| flumffy | The only issues I'm actively facing now are that the codegen for libc with LLVM 21 is broken in a way I've not investigated, along with the fact that enforcing PIE for static OpenBSD builds will need to be reintroduced (the code for this lived in the bintools wrapper at one point, but I think it's gone now). | 01:25:05 |
| emily | fwiw we'd quite like PIE for static builds in general; cf. https://github.com/NixOS/nixpkgs/pull/515233, the uncertainty has just been about the nicest way to accomplish that | 01:29:12 |
| emily | so maybe that can dovetail | 01:29:29 |
| emily | have you tried LLVM 22 btw? we're overdue to bump the default version anyway, so if it's a regression that got fixed… | 01:31:44 |
| flumffy | Not yet, I'll try that now. | 01:44:39 |
| flumffy | Seems to still be broken on LLVM 22.1.7, I'll dig into it further tomorrow if I have time | 02:37:10 |
 Alyssa Ross | yes, but note that older LLVM versions are liable for removal and if OpenBSD is the last user, that'll likely result in quite a bit of pressure to upgrade when removal time comes | 08:25:16 |
|  Enok Larsson joined the room. | 09:58:46 |
|  @rasmata:matrix.org joined the room. | 11:22:51 |
| @rasmata:matrix.org left the room. | 11:23:01 |
|  debtquity joined the room. | 19:18:02 |
| flumffy | Got it sorted on LLVM 21, should be okay on 22 as well (I wasn't keen on introducing a hack into the toplevel packages anyway, so this is nicer) | 19:50:13 |
|  citerism joined the room. | 23:25:37 |
| 24 Jun 2026 |
|  lzcunt set a profile picture. | 15:16:16 |
 Lun | In reply to @emilazy:matrix.org
fwiw we'd quite like PIE for static builds in general; cf. https://github.com/NixOS/nixpkgs/pull/515233, the uncertainty has just been about the nicest way to accomplish that Will rename and undraft tonight. Probably better to do sooner, naming being off or clang not having parity for a bit isn't a good reason for me to block it | 19:27:52 |
