| 9 Jan 2025 |
lzcunt | it seems libstdc++'s link test for binutilsNoLibc's ld fails because the link test expects a libc so it can't find crt1.o and other files | 16:45:11 |
lzcunt | So libstdc++ incorrectly believes binutilsNoLibc when built for a static target does not support -static | 16:45:45 |
lzcunt | do yall have any idea how this could be fixed? I couldn't find how musl handles this | 16:47:45 |
lzcunt | oh musl probably doesn't need libstdc++ right? | 16:49:49 |
lzcunt | could someone test https://github.com/NixOS/nixpkgs/pull/370683 with musl to see if it hits the same issue in pkgsStatic.stdenvNoLibc.cc.cc? | 16:51:46 |
lzcunt | * could someone test https://github.com/NixOS/nixpkgs/pull/370683 with musl to see if it hits the same issue in pkgsStatic.stdenvNoLibc.cc.cc? My poor laptop takes a bazillion years to compile gcc | 16:52:16 |
lzcunt | Yep I was right. Time to comment on the PR so it isn't accidentally merged until I figure out how this can be fixed | 17:06:28 |
lzcunt | * Yep I was right, it breaks musl too. Time to comment on the PR so it isn't accidentally merged until I figure out how this can be fixed | 17:08:47 |
emily | can mark as draft fwiw :) | 17:34:00 |
emily | I guess you could probably just override the detection for -static support, but I imagine not having a libc will probably break libstdc++ in general. | 17:34:29 |
lzcunt | i'm trying to understand how the managarm people fixed this so I can do the same but got a little busy, will look further into it this weekend | 17:49:54 |
lzcunt | I couldn't find how to mark a PR that's not a draft as a draft lol | 17:50:25 |
Alyssa Ross | It's under the reviewers | 17:51:13 |
Alyssa Ross | I just did it | 17:51:20 |
emily | it's in exactly the place marking it as ready for review isn't | 17:57:57 |
emily | to keep you on your toes | 17:58:00 |
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 |