Change:
ucommon = callPackage ../development/libraries/ucommon { }; <del> v8 = callPackage ../development/libraries/v8 { }; </del> <ins> v8 = darwin.apple_sdk_11_0.callPackage ../development/libraries/v8 { }; </ins> v8_8_x = callPackage ../development/libraries/v8/8_x.nix { };

Discussion:
V8 fails to build with: Steps to reproduce the behavior: v8 from latest unstable (v8-9.7.106.18) It seems the same issue has been discussed and fixed for nodejs here so the fix for v8 should be similar. Please run and paste the result.
Doesn't seem to be the only issue. After patching the dependency locally, I also get:
Related
This is a known issue that the Libsystem's math.h conflicts with libcxx
Just switching to as some similar issues mention did not solve the math include problem :(
You probably need to make a "proxy" derivation that only provides the necessary subset of headers from . Or you could just patch out the functionality that depends on sigpost.
I may poke around a bit, but it's unlikely I'll dig deep enough to solve it properly. So if anyone knows what they're doing, please have a look.
Some more research info: you can add to disable the feature requiring during compilation the next failure in that case becomes not being able to find which is expected in if you change that to then the compiler can't be found setting the environment variable to the path doesn't seem to do anything The build system of v8 doesn't seem to have a way to specify two base paths (one for clang / clang++ and one for llvm-ar), and nixpkgs has those in separate places.
Can use something like
Slow progress forwards, with the following changes: "v8enablesysteminstrumentation=false" clang base being a merge of and llvm the compilation goes further, but fails with: at the step. It looks like lld is not available on macos. There's this similar envoy issue: Unfortunately v8 doesn't expose as a variable. (well... it may be just ignoring it - it exists in the build files) There seems to be a which I tried setting to true, but it still requested lld anyway. Adding the package into the mix does not solve the problem - still can't use it.
Could it be that just needs to go to ? Alternatively, you probably can patch out the option from v8.
I'll give native inputs a go, but given it's in the same group of symlinks as clang (which works) I'm not expecting much. I looked at patching the option itself, however it doesn't exist directly in the v8 sources.

It could come from somewhere internal to bazel or ninja build systems.
I did a small test: It would seem like just having lld in the $PATH should be enough. From my experience with bazel, the rules_cc doesn't even use clang++, it always calls clang. So I'd guess you are dealing with some other build system. A useful check would be to run to see which tool sets that option.
So the actual step is: I'm pointing the at and that includes , , , so in theory all the needed parts - listing it in nix/store confirms. (it's in nativeBuildInputs too) I got nix to corrupt its store though, so I'm taking a break from this.
This does look like bazel.
No resolution yet, but some more info for future reference. After updating nix unstable and rebuilding things from scratch, I get more explicit warnings/errors: so clang++ is found and lld is found now as well. Not a common issue, there's only one reference at
Perhaps you could try monitoring the build with or add
With something adjacent seems to break so I don't even get to the LINK stage: but: trying other things...
Did you figure this one out
No, the last step was getting stuck with bash not visible. I'll post my last patch leading to that point soon in case anyone wants to continue.
Cool, thanks. I'll try it out and go from there.
This was my last attempt - I think that's the one failing with bash. I can't remember what was why by now, so changes like may be irrelevant. is definitely needed to work around the original issue of not being available. (unless you can fix the libsystem issue as well) is for lld/clang not found in the path.
I found that you can jus add to - is detected then, no need for wrapping clang and tools together.
Out of interest was a solution to found? or was the plan to just patch it out? I had a similar issue building deno because they moved aarch64-darwin to use that linker for speed, in the end I just patched it out
noted that v8 at version ‘v8-9.7.106.18’ has been marked broken since 14 May for x8664-darwin. Latest version that shows a good build is !?!?

I have a RoR nix env project that relies on v8 at the above version, and needs to upgrade to ruby3_1. So I had to perform a to grab latest flakes. But now I am unable to get my dev shell to boot up with following error: Is there any plan for the v8-9.7.106.18 fix soon? I am wondering how I can help to get this moving?
Not sure if anything improved since my post I could not reproduce 's fix on my side, but maybe I'm missing something - a link to a patch/commit would be useful. The only change since then is that with you don't need to disable the tracing feature if you use . But otherwise I haven't seen any solution to
Please test with It builds correctly on Intel, but don't have an M1 to validate.