Change:
] ++ lib.optionals (stdenv.hostPlatform.useLLVM or false) [ "-DLLVM_ENABLE_LIBCXX=ON" "-DLIBCXXABI_USE_LLVM_UNWINDER=ON" <del> ] ++ lib.optionals ((stdenv.hostPlatform.useLLVM or false) || (stdenv.hostPlatform.isDarwin && enableShared)) [ </del> <ins> ] ++ lib.optionals ((stdenv.hostPlatform.useLLVM or false) || !stdenv.hostPlatform.isDarwin) [ </ins> # libcxxabi's CMake looks as though it treats -nostdlib++ as implying -nostdlib, # but that does not appear to be the case for example when building # pkgsLLVM.libcxxabi (which uses clangNoCompilerRtWithLibc).

Discussion:
Steps to reproduce the behavior: libcxxabi on Darwin Could this be caused by ? (
Heads up, I'm about to be offline for a week, so I won't be able to respond after a few hours. I don't have a darwin machine so may need help to determine what's wrong (though I will take a look at expressions to see if I can spot what's wrong). 1) Please can you provide a commit hash of nixpkgs that you're building? 2) Are you able to test nixpkgs a) and b) ? If (b) fails, but not (a), then is implicated.
I'm currently unable to match your reproducer on the nixos-unstable or master branches, because I'm seeing a libcxxabi version 11, not 15 as you have. Please can you share exactly the nix expression you're trying to build with enough bits to reproduce.
It originally happened when doing , as a dependency of mpv, so this reproduces it: Edit: (Or just will do it)
The above was at And it does fail with but work with
cc If I get any spare fragments of time over the next couple of hours I will see if I can investigate, but if you don't hear from me soon, it will be after 2nd Sept, and I'll be busy when I get back. If this has to be reverted to un-break things then so be it but I hope we can get it working and reland it quickly once the issues are fixed (cc also
the only thing I see different between between the two commits is , and not the . What we ran with is: Where we pass these on darwin (only for shared). I originally developed this for LLVM 16 (and included that I think with your input though I can't quickly find the reference) and then subsequently backported it to LLVM 15 per request to keep it up to date. Is the condition wrong? if you're in a position to test, can you remove those two lines from so that those flags are not passed and retest?
If I remove those two lines, I get this: I can try again with if it helps, but I'm not sure how long it'll take.

I think what you've provided is evidence that those two lines are what broke it: when you remove the lines you get a cache hit (and cache hit is evidence the build succeeds). So I think what is in error is supplying those arguments. Please can you also test with and without the lines?
I see the same behaviour with : without those lines I get a cache hit, and with them I get the clang/linker error.
Thanks, then it seems the logic is wrong. I'm going away imminently, any chance you could send a PR to change the logic so that those lines are not present if isDarwin, and ping on it (who helped with the darwin side for my PR). If this is still outstanding in September feel free to ping me here.
It sounds like will all need updating, and the logic should read by the looks of things.
Yes, I'll do that later. Thank you for your help.
Thanks for the ping. I agree with the assessment on this. This was a gap in my testing. I only made sure the stdenv with clang 16 still built and static builds still worked. I missed checking non-stdenv builds. (Though I’m increasingly of the opinion that Darwin should always use the stdenv libc++ and libc++abi regardless of compiler version.) I’ve made the required changes locally. Once I’ve confirmed it builds, I’ll open a PR with the fix. Edit: If opens one, that’s also fine. I won’t be able to check the build status until this evening EDT.