 | Nix on macOS | 1207 Members |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 201 Servers |
| Nix on macOS | 1207 Members |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 201 Servers |
| Sender | Message | Time |
|---|---|---|
| 11 Apr 2026 | ||
 emily | ah, actually no | 20:27:32 |
| emily | that code path isn't used on Darwin I guess :) | 20:27:38 |
| emily | anyway, finding out more about weak exports… | 20:27:45 |
 Randy Eckenrode | dlopen defaults to RTLD_GLOBAL on Darwin. .NET doesn’t specify, so it gets that by default, which means symbols are resolved against the global namespace. | 21:25:35 |
| emily | no, it doesn't affect resolution; it means that the loaded library gets exported into the global namespace | 21:26:18 |
| emily | it should only be relevant if anything with -flat_namespace is linked in or you use dlsym with one of the special handles | 21:26:39 |
| Randy Eckenrode | -flat_namespace doesn’t matter. That was the problem with GStreamer. | 21:29:29 |
| Randy Eckenrode | But I feel like this is all beside the point. The question is how much work I have to do to get this fixed. If it’s a non-trivial amount, I’m just going to close the PR and let someone else fix it. | 21:31:42 |
| Randy Eckenrode |
It uses libicucore.dylib on Darwin. Native AoT also links against it. Changing it requires making a bunch of changes to .NET to use the upstream ICU instead. It also won’t work for binaries using | 21:33:28 |
| Randy Eckenrode | *
| 21:43:37 |
| Randy Eckenrode | *
It uses libicucore.dylib on Darwin. Native AoT also links against it. Changing it requires making a bunch of changes to .NET to use the upstream ICU instead. It also won’t work for binaries using | 21:43:44 |
| Randy Eckenrode | I have no idea why Element X renders that last one funny. | 21:44:03 |
| emily | this feels like a somewhat unfair response to me putting in hours of work and counting today investigating this and trying things to ensure that we don't continually run into OS updates breaking our binaries… | 21:46:42 |
| emily | AFAICT, in the limit, we would have to ensure that nothing we build ever has a weak export for any symbol that is now or could be in the SDK in future, because those will get coalesced ignoring two-level namespaces | 21:48:20 |
| Randy Eckenrode | I don’t have hours to deal with this. If resolving it is going to require more time than I can invest, then what else can I do? | 22:08:32 |
| 12 Apr 2026 | ||
 axw | lol I didn't think it was possible to configure any programs besides the ones officially supported by nix-darwin. Turns out you can declare settings for any Programm that has a plist file in Library/Prefrences/ | 00:07:32 |
| axw | * lol I didn't think it was possible to configure any programs besides the ones officially supported by nix-darwin. Turns out you can declare settings for any Programm that has a plist file in Library/Prefrences/. Not all have extensive options, but most that can be managed or are intended to be managed by an mdm | 00:09:35 |
 LogN [unavailable @ CinemaCon -> 4/18] joined the room. | 00:58:06 | |
 leona changed their profile picture. | 12:15:57 | |
 niklaskorz | Both your feelings are valid. I'm currently reading through emily's very thorough and valuable analysis in https://github.com/NixOS/nixpkgs/pull/506470 to understand the problem. I'll try to implement and verify Emily's suggestions to take off some pressure. If it doesn't work out, we can still come back to randy's PR to unblock dotnet at least. | 12:53:34 |
| Randy Eckenrode | I’m not trying to downplay the research @emily did, but I am lacking enthusiasm for the idea of working upstream on this, and if I go deep into this, it’s going to chew up what limited time I have. | 13:15:31 |
| Randy Eckenrode | Additionally, I actually need .NET for something I’m doing, so being broken is no good. | 13:16:15 |
| emily | fwiw, I tried the visibility annotation on the explicit instantiation with no luck - I think it's inherited from the template definition and from reading Clang code it seemed fairly hardcoded. everything I can find about Mach-O weak bindings implied that uses internal to a dylib should resolve to the symbol inside the dylib though. I also couldn't reproduce with a simple test program using dlopen on our ICU build while linking to Foundation. so I need to poke more at stuff there to figure out the true root cause of why this is happening to .NET | 13:47:26 |
| emily | I wouldn't be surprised if the re-exports have something to do with it, so using Apple's bundling code to create the libicucore is definitely nicely worth trying and not something I've tried yet. (possibly we could use the mergeable libraries stuff to make it less gross, if our ld64 supports that?) | 13:48:35 |
| emily | I'm hoping that figuring out exactly what's triggering this will point us to a more durable solution, because having to ensure we never have a weak symbol referencing anything that the system cache ever uses internally, now or in the future, would be super unsustainable. in the limit it's impossible to predict, but even in the immediate state it implies that building our own libxml2 is risky, and that's no good... | 13:51:21 |
| emily | I guess in the worst case we could try to teach tools to prefix every single symbol with _nix_, but... that would be a horrendous mess 🙃 so I am really hoping that we can make two-level namespaces keep working for us here | 13:53:16 |
| emily | ODR when it's something pervasive like libc++ that is linked directly into programs and can easily show up in ABIs etc. is one thing to step away from and say that we're going to just use the system one or prefix our symbols, but when it's internal implementation details of system stuff leaking that aren't otherwise exposed to consumers... TBH if it's not the result of .NET doing something really weird then it seems like a screwup on Apple's part to not use the platform facilities to hide that kind of thing, but it'll also really suck to have to play whack-a-mole and have existing binaries break on new OSes. since I don't have a minimal reproducer yet I'm optimistic that in the usual case this stuff doesn't actually leak and that it's not as bad as it sounds. but I will need to dig some more. I'm also surprised if nobody other than Nixpkgs has run into this which increases my feeling that it's something messed up about .NET. | 13:59:13 |
| emily | (ODR also only covers full programs and the C++ standard's position on runtime dynamic loading in a system with two-level namespaces is ❓... given the complete encapsulation in the system framework here I feel we ought to be in the clear as long as we are correctly interoping for fundamentals like unwinding and RTTI, which we should be these days) | 14:01:51 |
| emily | anyway, would be very interested to hear how it goes if you get the Apple dylib merging step working | 14:02:20 |
| emily | unfortunately not sure a simpler way to test than building .NET as I'd expect we'll still get weak exports in the monolithic dylib even if it fixes the issue | 14:03:14 |