| 9 Jan 2025 |
 lzcunt | I think gcc needs --disable-hosted-libstdcxx when building for nolibc which should make libstdcxx freestanding and hopefully make everything happy | 18:28:54 |
 Greg Hellings | Looks like pkgsCross.mingwW64.icu is broken currently. I'm getting a handful of errors that look similar to this one:
/nix/store/zc3w94hsr3y61af27x3110xhqabxfpcv-x86_64-w64-mingw32-gcc-14-20241116/include/c++/14-20241116/limits:2100:30: error: exponent has no digits
2100 | return __extension__ 0x1.0p-16382Q;
| ^~~~~~
/nix/store/zc3w94hsr3y61af27x3110xhqabxfpcv-x86_64-w64-mingw32-gcc-14-20241116/include/c++/14-20241116/limits:2114:30: error: exponent has no digits
2114 | return __extension__ 0x1.ffffffffffffffffffffffffffffp+16383Q;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 21:44:48 |
| Greg Hellings | Based on where the error is coming from, other packages might be affected, as it appears to be coming from the bundled C++ headers | 21:45:42 |
| Greg Hellings | Seems like this is the same error: https://github.com/NixOS/nixpkgs/pull/261341 - gonna see if I can get a similar fix in for ICU | 21:48:02 |
| Greg Hellings | OK, so the error is already fixed in ICU 76. But the default ICU across nixpkgs is still ICU 74. Would it be better to try and develop a patch for ICU74 to address this? The change is relatively simple. Or to change the default to ICU 76 for MinGW builds? | 22:42:02 |
 K900 | Didn't we bump ICU this staging cycle? | 22:45:53 |
| K900 | @emily | 22:45:55 |
| Greg Hellings | 🤷 Looking at master right now it says icu = icu74; | 22:46:19 |
| K900 | Look at staging | 22:46:27 |
| K900 | * Look at staging-next | 22:46:30 |
| Greg Hellings | icuReal = icu74;
icu = if stdenv.hostPlatform.isDarwin then darwin.ICU else icuReal;
| 22:48:00 |
| Greg Hellings | That's different from master where it is just icu = icu74;, but still not revving it to 76 | 22:48:22 |
| K900 | Oh OK | 22:49:02 |
| K900 | Then I guess we'll have to update it eventually | 22:49:15 |
| K900 | I guess it can be done conditionally on mingw but I'd rather just update it everywhere | 22:49:27 |
| Greg Hellings | Updating it everywhere sounds like a job for staging next, and not me randomly proposing a change to master. 😆 | 22:49:59 |
| Greg Hellings | Currently testing the ucrt Windows build to see if it is limited to MinGW or if it's all Windows. The way I understand the bug and the code I'm seeing it should be MinGW specific | 22:50:36 |
| Greg Hellings | Yeah, ucrt with CLang builds fine with ICU74 | 22:50:53 |
| K900 | In reply to@greg:thehellings.com
Updating it everywhere sounds like a job for staging next, and not me randomly proposing a change to master. 😆 Yes | 22:51:13 |
| Greg Hellings | Wait, no, that was me building ucrt with icu76. Trying again with 74 | 22:51:32 |
| Greg Hellings | OK, yeah, this is limited to only failing on MinGW as I thought. The naughty code is behind ifdef's for MinGW, so that's expected | 22:53:09 |
| Greg Hellings | Should I prepare a limited PR for master to just rev it for mingw? Or is staging updating it everywhere in the near future? | 22:54:49 |
| K900 | In reply to@greg:thehellings.com
Should I prepare a limited PR for master to just rev it for mingw? Or is staging updating it everywhere in the near future? I would prefer the latter | 22:58:32 |
| K900 | Any sort of "this obscure platform uses this other thing instead of the normal thing" conditionals explode given enough time | 22:58:52 |
| Greg Hellings | Agreed. I don't know about calling Windows obscure, but it's definitely a corner case for nixpkgs | 23:00:42 |
| K900 | Windows is not obscure | 23:06:02 |
| K900 | MinGW is, extremely | 23:06:07 |
| 10 Jan 2025 |
 emily | don't we use MinGW for all Windows cross | 00:59:24 |
| K900 | In reply to @emilazy:matrix.org
don't we use MinGW for all Windows cross Yes, which we have very little of | 07:14:40 |
| Greg Hellings | Yes, but only with gcc on some of them. And the build failure is mingw+gcc-14+ specific. For ucrt targets we seem to use clang instead and that did not manifest the failure | 15:33:12 |
