Change:
in stdenv.mkDerivation rec { pname = "opencl-clang"; <del> version = "unstable-2021-06-22"; </del> <ins> version = "unstable-2022-03-16"; </ins> inherit passthru; src = fetchFromGitHub { owner = "intel"; repo = "opencl-clang"; <del> rev = "fd68f64b33e67d58f6c36b9e25c31c1178a1962a"; sha256 = "sha256-q1YPBb/LY67iEuQx1fMUQD/I7OsNfobW3yNfJxLXx3E="; </del> <ins> rev = "bbdd1587f577397a105c900be114b56755d1f7dc"; sha256 = "sha256-qEZoQ6h4XAvSnJ7/gLXBb1qrzeYa6Jp6nij9VFo8MwQ="; </ins> }; patches = [

Discussion:
I use intel-compute-runtime to provide opencl to darktable and it's not being fetched from the cache since today 2022-04-22 Also, compiling intel-graphics-compiler (which is a dependency) fails so I had to remove it altogether. Steps to reproduce the behavior: Get's installed from cache Please run and paste the result.
When running the line I see:
The problem is in this: It seams that upstream has fixed it long ago: Upgrading at least to 1.0.9289 could fix the problem.
I get the same error: Any workarounds?
Seems like is inactive.
Upgrading and therefore , , , , and seems to do the trick for me BUT, i don't really have a clue what i'm doing...
so probably we just need someone to update the version here.
that is indeed inevitable, i guess. I had to do some trickery regarding the compilation of and , else it would segfault when compiling with something like which seems to happen when two different clang compilations are present in the build environment. (guess this is the case when building with ) , , , and similar in Now that i have the new versions running, i tried to somehow confirm a working solution and ran like in and it coredumped with that same message as well, so i'm uncertain if this is caused by my changes or if it failed before that anyway. Is coredumping for you as well right now, even without the updated versions?
Hmm, just tried to run in my previous NixOS generation. It gave some output and did not segfault. So my current approach is compiling but seems to not work correctly.
Woah, had in their . This produces a pkgconfig of e.g. So we need to patch with something like Another case for
So far is building, but the depender is failing to build its test suite, because of probably? is linked statically into , a dependee of . Which probably leads to being statically present and hence causing this segfault? See also
Now this builds and does not segfault any longer. I gues the main trick was to add to s to make it compile a shared instead of the static . It seems like the static led to the segfault by including libLLVM statically into the build and when calling functions of libLLVM it got confused about its split personality?

i don't know.
So I was allready working on a PR for this and I only just now found this thread. The approach I took is similar to but I didn't update , and since the versions in nixpkgs are already newer. Once I verified it works for me I can send in a PR. I was also the one who did the last update.
beautiful :) Did you also find the switch in and being unnecessary? Also i noticed some of the existing do not apply any longer and need to be cleaned up. The llvm testing tool needs some more work though, got it to work for the static version of but not for the dynamic one.
I'm curious if this is going to work correctly with newer versions of and , i found those being restricted by the release description of at
I didn't even touch . Intel tools always pin a very specific version. Honestly it's quite bad practice from Intel but unless it's really necessary I don't want to downgrade them. They were updated by someone for a reason. If they won't work we would need to duplicate them which is also not so nice. For this same reason I don't want to touch the patches. It might be that IGC doesn't need them. But they were included in the project for a reason. In fact if you look at the current branch there are no patches anymore. It's always a balance since you never know what will depend on these packages in the future. I'd rather keep the changes to a minimum.
Ahh, thanks for the clarification, now i see why i couldn't make sense of the patching mechanism. :)
it's a bit offtopic, but i'm curious to know. Do you understand and care to explain to me some details of why this segfault happened when the was present and linked/loaded into the build of within the test run or at runtime through ?
Honestly I have no idea. I know there were some idiosyncrasies with the and linking. See here; But since I didn't see this issue I don't really know why it happened. I would have to investigate myself.
PR is out my system runs fine with the additions. works.