treewide: drop LLVM11

[ghost]

Description of changes

unpin llvm11 from freshbootstraptools and drop LLVM11. i have a PR in review to update the bootstrap-tools for darwin which should be merged soonish #295557

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[ghost]

as per @reckenrode

Bootstrap tools should probably be the minimally supported version of LLVM to prevent accidentally depending on the bootstrap version of LLVM matching the version in the stdenv.

so that will need to be changed from llvmPackages_16.

[reckenrode]

To elaborate on that a bit, I want to avoid assumptions about the bootstrap compiler lest it cause trouble for future LLVM version updates for Darwin. In theory, it only matters if the bootstrap tools are ever updated, and the breakage would have to happen between now and when the switch is made to LLVM 18., so the risk is low. It may not be worth changing the version if it creates more work. (Assuming the SDK issue with libc++ can be addressed.)

[elliottslaughter]

Please be aware that if you remove LLVM 11, you will need to disable Terra on Linux ARM due to this outstanding issue: terralang/terra#597

On every system other than Linux ARM, Terra can go up to LLVM 17 if needed, but the Linux ARM bug keeps that platform on LLVM 11.

[ghost]

Please be aware that if you remove LLVM 11, you will need to disable Terra on Linux ARM due to this outstanding issue: terralang/terra#597

On every system other than Linux ARM, Terra can go up to LLVM 17 if needed, but the Linux ARM bug keeps that platform on LLVM 11.

the build fails when trying to compile with an llvm above 13. eg, with llvm16

CMake Error at src/CMakeLists.txt:229 (target_link_libraries):
  Target "TerraLibraryShared" links to:
FFI::ffi

but the target was not found.  Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.

CMake Error at src/CMakeLists.txt:345 (target_link_libraries):

Target "TerraExecutable" links to:
FFI::ffi

but the target was not found.  Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.

[elliottslaughter]

@a-n-n-a-l-e-e let me know if I should move this discussion to a different thread; until then I'll just reply here.

That looks like a missing dependency. In general, Terra only relies on a minimal LLVM build. (For our builds, I usually turn off all the optional build flags.) It's fine if you built LLVM with optional dependencies but then that means you'll have to add those dependencies to Terra.

I'm not an expert on what this FFI is but I've noticed that in many distros, the set of default LLVM dependencies has been creeping up over time (even though LLVM actually does not require them to be enabled). I would consult the LLVM build itself to determine what this FFI is and then add it to Terra, and see if that fixes it.

I see I forgot to release the current support for LLVM 17 in Terra, which I'll probably do shortly. Until then, version 1.1.1 supports up to LLVM 16.

[ghost]

thanks @elliottslaughter. PR updated with llvm16. just needed to add libffi and update a path.