Before the change `llvmPackages.bintools.bintools.targetPrefix` was not
present. This exposed as a discrepansy between `binutils` and `llvm`:
`binutils`:
nix-repl> stdenv.cc.bintools.bintools.targetPrefix
""
nix-repl> stdenv.cc.bintools.targetPrefix
""
`llvm`:
nix-repl> pkgsLLVM.stdenv.cc.bintools.targetPrefix
"x86_64-unknown-linux-gnu-"
nix-repl> pkgsLLVM.stdenv.cc.bintools.bintools.targetPrefix
error:
error: attribute 'targetPrefix' missing
As a result some attributes like `pkgsLLVM.actionlint` failed to
evaluate:
$ nix build --no-link -f. pkgsLLVM.actionlint
...
error: attribute 'targetPrefix' missing
at pkgs/development/compilers/ghc/9.4.8.nix:232:46:
231| export READELF="${targetCC.bintools.bintools}/bin/${targetCC.bintools.targetPrefix}readelf"
232| export STRIP="${bintoolsFor.strip}/bin/${bintoolsFor.strip.targetPrefix}strip"
| ^
The change exposes binary prefix the same way as `binutils` does.
It appears that LLVM's build system no longer sets the executable's
rpath to include the faux resource root we pass in, so we need to make
sure cc-wrapper does this.
compiler-rt includes <linux/unistd.h> on RISC-V. This only seems to
be necessary for useLLVM, but looking at the source code I can't
see any reason for that, so probably in the non-useLLVM case it just
gets propagated in.
for hygiene
Run `deadnix . --edit`
`gccForLibs` is an argument used by multi.nix but it's an argument to
cc-wrapper, not to llvmPackages.
`@args` in `llvm/default.nix` was accidentally added in 4badff49fd
There are no uses of `@` therefore these changes are safe.
While using very old compilers is a fair usecase, it induces a maintenance churn as
we collect more and more LLVM versions for the LLVM maintainers.
Especially when we need to backport uniform changes to the whole tree,
furthermore, it consumes and waste CI resources.
CMake commit faa950a155 ("try_compile: Run native build tool with verbose output")
did not play well with these versions of openmp, which have a faulty
failure regex that considers "unknown" in the build output to indicate
a failure. When cross compiling, the string "unknown" is very likely
to occur as part of triples. Fix by backporting a patch that improves
the failure regex check to not be tripped up by triples.
The same problem affects LLVM 11 and possibly earlier, but the patch
doesn't apply that far back, so I didn't bother for now.
Fixes: b8ac5b6cfb ("cmake: 3.25.3 -> 3.26.4")
