 | Nix on macOS | 1213 Members |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 203 Servers |
| Nix on macOS | 1213 Members |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 203 Servers |
| Sender | Message | Time |
|---|---|---|
| 11 Apr 2026 | ||
 emily | presumably because explicit template instantiations are weird abs nobody thought about it | 19:35:55 |
| emily | I'm not 100% confident it'd get rid of the weak export but it's trivial to check since the linker can bail out on it without having to compile .NET or anything | 19:36:47 |
| emily | that said it would be nice to not have to be afraid of Apple screwing things up for us with clashing symbols, incl. C ones, in the presence of weak stuff. so I'm still figuring out if my understanding of weak exports is fully accurate and if there's a better way | 19:37:56 |
| emily | my suspicion is the explicit instantiation with no visibility annotation + -fvisibility=hidden -> weak export and with the correct visibility used for all other C++ defns it'd become strong and never get resolved elsewhere | 19:39:54 |
| emily | per usual two-level namespace rules | 19:40:10 |
| emily | https://github.com/llvm/llvm-project/blob/0c0ae3786ef4ec04ba0dc9cdd565b68ec486498a/lld/MachO/InputFiles.cpp#L681 makes me wonder if this would even happen with LLD... | 19:54:41 |
| emily | btw, it looks to me like .NET will handle the versioned symbols just fine fwiw https://github.com/dotnet/dotnet/blob/36afe73557f5f93cd7bc827cb644a3ff018eca0b/src/runtime/src/native/libs/System.Globalization.Native/pal_icushim.c#L60-L61 | 20:26:32 |
| 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 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 |