[21.11] llvmPackages_14: 14.0.0rc1 -> 14.0.1

[ggreif]

This (mostly) catches up with master branch and unbreaks llvm_14 and dependents.

This is the difference vs. master:

$ git diff nixos/master HEAD -- pkgs/development/compilers/llvm/14
diff --git a/pkgs/development/compilers/llvm/14/lld/default.nix b/pkgs/development/compilers/llvm/14/lld/default.nix
index 1ae6d4ea6fc..fe655c76112 100644
--- a/pkgs/development/compilers/llvm/14/lld/default.nix
+++ b/pkgs/development/compilers/llvm/14/lld/default.nix
@@ -42,7 +42,7 @@ stdenv.mkDerivation rec {
 
   meta = llvm_meta // {
     homepage = "https://lld.llvm.org/";
-    description = "The LLVM linker (unwrapped)";
+    description = "The LLVM linker";
     longDescription = ''
       LLD is a linker from the LLVM project that is a drop-in replacement for
       system linkers and runs much faster than them. It also provides features
diff --git a/pkgs/development/compilers/llvm/14/llvm/default.nix b/pkgs/development/compilers/llvm/14/llvm/default.nix
index ea147337831..05aac728b45 100644
--- a/pkgs/development/compilers/llvm/14/llvm/default.nix
+++ b/pkgs/development/compilers/llvm/14/llvm/default.nix
@@ -200,12 +200,6 @@ in stdenv.mkDerivation (rec {
     ln -s $lib/lib/libLLVM.dylib $lib/lib/libLLVM-${shortVersion}.dylib
     ln -s $lib/lib/libLLVM.dylib $lib/lib/libLLVM-${release_version}.dylib
   ''
-  + optionalString enableSharedLibraries ''
-    mkdir -p $dev/lib
-    mv $lib/lib/*.a $dev/lib
-    sed -i -E "s|$lib/lib/(.*)\.a|$dev/lib/\1\.a|" \
-      "$dev/lib/cmake/llvm/LLVMExports-${if debugVersion then "debug" else "release"}.cmake"
-  ''
   + optionalString (stdenv.buildPlatform != stdenv.hostPlatform) ''
     cp NATIVE/bin/llvm-config $dev/bin/llvm-config-native
   '';

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 22.05 Release Notes (or backporting 21.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
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[ggreif]

@GrahamcOfBorg build llvm_14

[primeos]

Please use git cherry-pick -x <original commit>, see https://nixos.org/manual/nixpkgs/stable/#submitting-changes-stable-release-branches.

[ggreif]

Please use git cherry-pick -x <original commit>, see https://nixos.org/manual/nixpkgs/stable/#submitting-changes-stable-release-branches.

@primeos that is fine, but it is not just one commit, but this list:

git cherry-pick -x 1748887ff23 dd8169da3e4 90d9b7c8dc7 f0c2e464685 c9cfbe08995 641c2d3b7b6 790c4f13dd8 5e04d64aed1 7151381aab2 4f3116f7542 2efcc3e297a 6d111cbf615 075c5eb8d39 84dbfa8f970

One of those updates other llvm directories besides 14. Is it okay to submit here (or should it be backed out)? Maybe it should be submitted as staging?

EDIT: I think removing these should be acceptable:

• 7a948957d8e17627e36c17f29ab778e0b96b08bb
• ead5e367342221f6174d18430b3854c427ad3198

That leaves us with one change in pkgs/development/compilers/llvm/update.sh. I am not in the position to say if those changes are okay for the release branch.

[primeos]

@primeos that is fine, but it is not just one commit, but this list:

Yes, that's fine ;)

Can you provide some guidance how to proceed with these?

I usually do one of two things (after examining the commit):
a) I don't cherry-pick the commit (because it's optional, requires other commits with major changes, etc.)
b) I only cherry-pick the relevant changes (i.e., pkgs/development/compilers/llvm/14 in this case; requires a bit of Git fu) and make it clear in the commit message (e.g., by changing openmp: new fix-find-tools patch to llvmPackages_14.openmp: new fix-find-tools patch)
Edit: Oh, and if the commit requires changes to other files that could be considered breaking or require staging, I usually leave them out (unless they provide important fixes vs. new features, etc.).

In this case I didn't cherry-pick any of those commits since NixOS 22.05 is imminent and I only care about Chromium but it's of course fine to backport those commits.

[ggreif]

@primeos Okay, PTAL. pkgs/development/compilers/llvm/update.sh is probably necessary, I am happy to incorporate your input there.

[ggreif]

@primeos Sadly the Darwin builders ofBorg time out after an hour, but both Linux builders have produced results. So I guess this is an improvement.

[risicle]

nixpkgs-review reveals no new failures on macos 10.15

[ggreif]

@dtzWill @primeos anything I can do to speed this up?

[primeos]

Not really, I just don't have that much time anymore so it takes me a bit sometimes (but feel free to re-ping me after a few days in case I forgot about something).

[primeos]

Diff and commits LGTM (I did a few Git checks to verify it). CI is also fine so it should be good to go :) Thanks for the PR!