In 7869d16545 I got rid of the symlinking
by forcing `COMPILER_RT_OS_DIR` to always be the empty string. I thought
this was good because it just make compiler-rt be installed in a normal
way.
However, various LLVM tools expect the `COMPILER_RT_OS_DIR` to be set
normally, and fail to find things when they aren't in the expected lib
subdir.
Maybe it would be best to patch that too in the long term, but for now
we just undo this change.
Rust 1.50.0 incorporated a Cargo change (rust-lang/cargo#8937) in
which cargo vendor erroneously changed permissions of vendored
crates. This was fixed in Rust
1.51.0 (rust-lang/cargo#9131). Unfortunately, this means that all
cargoSha256/cargoHashes produced during the Rust 1.50.0 cycle are
potentially broken.
This change updates cargoSha256/cargoHash tree-wide.
Fixes#121994.
Before, clang was able to find some headers with a relative path to the
`-B` flag pointing near the unwrapped clang binary. But with multiple
outputs that doesn't work, so we use a "resource directory" as it done
later in the bootstrap.
(It was requested by them.)
I left one case due to fetching from their personal repo:
pkgs/desktops/pantheon/desktop/extra-elementary-contracts/default.nix
The tarball download URLs seem to have changed, so we adjust them in
case anyone wants to reproduce the source of ghc8102Binary and
ghc865Binary.
Tested for x86_64-linux, i686-linux, aarch64-linux, x86_64-darwin.
Resolves#121804.
Manipulating the store paths on the Nix side doesn’t work with CA
derivations (because these paths are just placeholders of the form
`/{hash}` at eval-time)
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
Provides a few hopefully helpful pointers that would not work well as
inline comments in the expressions themselves. Most likely the README
will need to be expanded upon over time to cover how we handle the Julia
release process, but I hope this is a good starting point.
Provides very little comfort compared what is outlined in the
manual [1], only supports a single version, and would probably be better
to implement as a general Nixpkg tool.
[1]: https://nixos.org/manual/nixpkgs/stable/#sec-source-hashes
As far as I can tell this patch is redundant as all pre-compiled code
generated at build time is baked into the Julia system image and will
thus never get invalidated: Note that for both julia_10 and julia_15
there are no `.ji` files produced in the derivations.
buildPackages.stdenv.cc.cc is a C compiler that runs on the build
platform and produces binaries for the host platform. This is not
what we want. Also pkgsHostTarget.stdenv.cc is not the compiler we
want as stdenv always runs on the previous stage so to say (the stdenv
is used to build the package set, in the case of cross compiling
this is not done natively). Thus pkgsHostTarget.targetPackages.stdenv.cc
is what we want.
This might be a bit debatable but upstream uses "xx" instead of "++"
when using it as identifier / in the code (file/directory names, build
scripts, website URLs, etc.) so we should probably too.
And at least the attribute name and pname will be consistent now.
mrustc is mostly patched to use shared LLVM sources but still uses
in-tree source for compiler-rt from LLVM 7. This needs to be patched to
compile under glibc 2.31 or later. It's easy enough to reapply all our
compiler-rt patches here.
This patch was applied to gcc7 in aab8c7ba43 ("netbsd: add cross target"),
but it hasn't been brought forward to newer compilers that have the
same problem.
GCC 6 and (probably) GCC 4.9 also have the issue, but the patch
doesn't apply cleanly to them so I'm leaving them alone for now.
GCC 10, our current default, appears to have finally fixed this.
Remove old CUDA toolkits (and corresponding CuDNN versions).
- Not supported by upstream anymore.
- We do not use them in nixpkgs.
- We do not test or actively maintain them.
- Anything but ancient GPUs is supported by newer toolkits.
Fixes#107131.
In 486e12ad68 cmake flags were added matching
later compilers use of libunwind for `useLLVM = true`. Unfortunately, `useLLVM`
on Darwin was not something tested before, and so the other compilers led us
astray: one of the new flags tried to make libunwind be used when it wasn't a
dep.
This is now fixed with more conditional code, but I hope things can perhaps be
made simpler with more insight into why libunwind is skipped. Perhaps it is
included in libSystem?
Finally, I moved the definition of `cmakeFlags` to match the order in the other
llvm versions.
CC @sternenseemann and @thefloweringash
This flag was introduced for clang 9, but we use it in the `lldClang`
wrapper for `llvmPackages` 7, 8 and 9. For this purpose the patch was
backported for `llvmPackages_8.clang`, but not for `llvmPackages_7.clang`
which has been done in this commit.
`lldClang` is mostly used when cross compiling and
`stdenv.hostPlatform.useLLVM` is true. Most likely this problem wasn't
noticed since `useLLVM` with `llvmPackages_7` was broken for other
reasons as well and all cross targets (like `wasi32`) which have
`useLLVM` at the moment use `llvmPackages_8`.
With this change tests.cross.llvm.hello.{musl64, …} works again.
This reverts commit 76b54c75b3 and brings
llvmPackages_7.libcxxabi in line with what the other llvmPackages
sets are doing again (with llvmPackages_7 being the sole outlier).
This also fixes an evaluation error of llvmPackages_7.libcxxabi if
stdenv.hostPlatform.useLLVM is true as the nonexistant libunwind
argument would be overridden.
This commit patches one of the llvm-exegesis tests to swap out whatever
CPU model happens to be on the build host for bdver2 (AMD Family
15h/Piledriver), which was picked because it looks like that was the
intent of the test author. This provides a more predictable compilation
behaviour when running on older (or possibly even newer!) machines.
One of the machines that is currently part of the NixOS Hydra build
farm, wendy, is using an old AMD Opteron CPU for which LLVM has no
scheduling machine model. This causes one of the tests for llvm-exegesis
to fail, because it segfaults trying to use the machine model to produce
useful analysis results.
Note that this particular test only runs on x86-64 build hosts anyway;
aarch64 isn't affected.
This deliberately only patches LLVM 12 to limit the rebuilds; other
LLVM versions are going through staging.
Don't rely on gcc detecting from the passed platforms which prefix to
use, but always specify the prefix nixpkgs expects (or doesn't). This
allows us to work around problems where the configure script would add
prefix where nixpkgs doesn't expect one (if `--target` was specified,
but the same as `--host`) or doesn't add one if nixpkgs expects one (if
`--target` and `--host` are the same, but we are actually cross
compiling, but the relevant parts of the platform are not encoded into
the platform config.
See also ca9be0511b.
It is building fine locally, tested by myself and @SuperSandro2000 (who had added the broken tag).
Should this be tested on hydra before removing it? I don't know if that is even possible.
