llvmPackages_{12,13,14,15,16,17}: drop

[emilazy]

We currently package ten stable versions of LLVM going back 4½ years. Older versions of LLVM don’t get upstream fixes, and require significant derivation complexity and patching to keep working, especially the further back we go. Dropping them eases the burden of LLVM maintenance and saves a bunch of expensive compiler builds on Hydra.

The packages marked broken or dropped here will be the only remaining users in the tree after the remaining in‐flight PRs are merged. I made varying degrees of effort to get all of them building with newer versions, as per the list of preceding PRs below, but was not successful in these cases. The upstreams have varying degrees of activity. If anyone can get them building with LLVM ≥ 18 then they can be removed from this PR or re‐added after it is merged. I’ve left some notes in the commit messages and code comments where applicable for anyone who wants to try. I do hope that we will drop old compilers more regularly going forward, though, so I wouldn’t recommend making a one‐off heroic effort if it’s expected that it will end up bitrotting again a couple releases down the line. In particular, I hope that we will be able to drop at least LLVM 18 for 26.05.

This concludes my work to drop old compilers for 25.11 – reviews of open PRs are appreciated:

• various: unpin old GCCs #434139
• sgx-sdk: unpin GCC #434553
• various: unpin or bump LLVM #434642
• zig_0_12: drop #434644
• androidndkPackages_{21,23,24,25,26}: drop #434649
• {irods,irods-icommands}: 4.3.3 -> 5.0.1 #434776
• ante: unstable-2023-12-18 -> 0-unstable-2025-07-12 #434788
• cudaPackages_{11,12_0,12_1,12_2,12_3,12_4,12_5}: drop #434827
• {gcc9,gcc10,gcc11,gcc12}: drop #435019
• creduce: 2.10.0 -> 2.10.0-unstable-2024-06-01 #435063
• bazel: bazel_6 -> bazel_7; bazel_6: drop #435096
• bazel_7: fix build with modern Clang on macOS #435110
• emacs-macport: use a different hammer for the CF_NOESCAPE bug #435148
• klee: 3.1 -> 3.1-unstable-2025-07-11, bump to LLVM 18 #435927
• python313Packages.verilogae: switch to maintained fork #435932
• python313Packages.llvmlite: 0.44.0 -> 0.45.0rc1; python313Packages.numba: 0.61.2 -> 0.62.0rc1 #437152
• sparse: 0.6.4 -> 0.6.4-unstable-2024-02-03 #437364
• swiftPackages.*: build with the default LLVM version #439408
• cling: 1.0 -> 1.2-unstable-2025-09-01 #439740
• {crystal_1_14,crystal_1_15,crystal_1_16,crystal_1_17}: bump LLVM; crystal_1_11: drop #439928
• haskell.compiler.ghc902Binary: bump LLVM by wrapping opt(1) #440271
• {intel-compute-runtime{,-legacy1},intel-graphics-compiler}: drop; opencl-clang: 15.0.1 -> 21.1.0 #440272

cc’ing maintainers of packages marked broken or dropped in this PR:

• shader-slang (LLVM backend only) – @niklaskorz
• fpc (x86_64-darwin only) – @7c6f434c
• mrustc-bootstrap – @progval @r-burns
• spirv-llvm-translator (LLVM 14–17 versions only) – @gloaming
• bfc – @figsoda
• ikos – @AtnNn
• oclgrind – @athas
• cone – nobody 😢
• dale – @amiloradovsky
• wavm – @ereslibre
• qrscan – @sayanarijit
• hobbes – @kthielen @thmzlt

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

Sorry for the typo @niklaskorz 😅

[niklaskorz]

re shader-slang, I'll reference the discussion in #436961

TL;DR: the LLVM mode is in a weird (non-functional) state anyway, so we'll probably have to refactor or remove it. Upstream currently doesn't seem capable to keep up with recent LLVM versions, so removing withLLVM might even be preferred for now.

I'm fine with simply marking it broken here so we can defer that decision.

[emilazy]

Cool, thank you for the pointer! That is one of the packages I was most worried about so it is good to hear it at least won't be getting any more broken. I think I did not spend too long seeing how much work it would be to get it building with newer LLVM versions, so it's possible that it might be an upstreamable patch away from working. But I lack the context to know whether it'd be worth the energy, beyond what they have written down in their docs. I suppose if it's like most use cases for shaders then CPU execution isn't a priority.

[philiptaron]

Thanks, @emilazy.

[alyssais]

Lovely :)

[emilazy]

Thanks for the kind words :) I hope that we can drop old compilers at a more steady pace going forward now that the up‐front cost of catching up has been paid.

I believe I have fixed most of the review comments; would appreciate reviewers double‐checking and marking resolved anything they think has been appropriately handled.

[sternenseemann]

Nice to see some of the ugly conditionals disappear (e.g. from #347887 and #348568 🤐)!

• 54d55876a456180a837ca467b6f6124e199cab15 seems to prematurely remove some patches that belong in the LLVM 15 removal commit.

[sternenseemann]

This can't be folded into the previous conditional in the LLVM 13 removal, but needs to be its own, unconditional list.

[emilazy]

Good catch, thank you. Will split this up between the two commits.

[sternenseemann]

Do we…?

[emilazy]

Apparently not, since we’ve gone this long without it? It was added in 99eeff0 without explanation. I guess it was intended to resolve… an issue with Musl on PowerPC defining pt_regs?

I don’t know if the LLDB source would still run into this, but this Musl commit implies that it has not been an issue since 2019, regardless of LLVM version. In any case I think we would not accept a patch for an issue with PowerPC and Musl today without it being sent upstream to LLVM or Musl.

The i686 stuff in that patch, I don’t know. It’s not even related to the <sys/procfs.h> issue so I don’t know why it was added there in b4ee532, but I think LLDB on i686 is also marginal enough that any relevant fixes should go upstream, if they’re even still needed. cc @rrbutani who added it.

In any case it would cause a rebuild to port it forward here, of course.

[emilazy]

Nice to see some of the ugly conditionals disappear (e.g. from #347887 and #348568 🤐)!

I do appreciate the effort to get those unified with the rest of the LLVM builds :) But it also definitely exposed how much divergence there was across our wide version range, so I’m happy for the packaging to get a lot less tangled. (Though some of it could have been resolved by just eating rebuilds, of course, but there’s still essential stuff around build system differences and tons of patches that is satisfying to drop.)

• 54d5587 seems to prematurely remove some patches that belong in the LLVM 15 removal commit.

You’re right. getVersionFile has even worse semantics than I thought. I thought that if there are entries in common/patches.nix then it only looks at those, and only otherwise it falls back to looking in the versioned directory directly. But actually any omitted range falls back to a version‐specific directory, and this is seemingly used only for LLVM 15. WTF? I will fix this.

I think the whole patching machinery should probably be done differently. I have ideas for that, but I need a break from looking at this stuff first.

[emilazy]

Everything required here has now been merged into master, and this rebuilds only tests.cc-wrapper.supported and things downstream of the manual, as expected. I also added a release note. I’ll leave the button for someone else to push :)

[samestep]

@emilazy thank you for the awesome work in this PR!

Regarding Slang, I agree with your and @niklaskorz's assessment that it's not a high priority:

Cool, thank you for the pointer! That is one of the packages I was most worried about so it is good to hear it at least won't be getting any more broken. I think I did not spend too long seeing how much work it would be to get it building with newer LLVM versions, so it's possible that it might be an upstreamable patch away from working. But I lack the context to know whether it'd be worth the energy, beyond what they have written down in their docs. I suppose if it's like most use cases for shaders then CPU execution isn't a priority.

In case someone does decide to try that in the future, though, shader-slang/slang#8038 should be a good starting point. Here are the upstream LLVM changes that accounts for:

• llvm/llvm-project@ed98c1b
• llvm/llvm-project@93471e6
• llvm/llvm-project@16dcbb5
• llvm/llvm-project@8b1771b
• llvm/llvm-project@5746002
• [FileCheck] Don't use regex to find prefixes llvm/llvm-project#72237

As I mentioned in shader-slang/slang#8028 (comment), that PR did build successfully, but some of the tests did not pass, which is why it wasn't merged back then.