Staging next #123279
Staging next #123279
Conversation
If things build fine with `stdenvNoCC`, let them use that. If tools might be prefixed, prepare for that, either by directly splicing or just using the env vars provided by the wrapper setup-hooks. Co-authored-by: Dmitry Kalinkin <[email protected]>
darwin packages: Get ready for cross
* Use LLVM_PATH instead of llvm-config * Pass less unnecessary options to cmake
This keeps the "main bootstrap" together.
This decision was made in a902d99 but just for LLVM 12. Now we apply it consitently.
- Introduce `preLibcCrossHeaders` to bootstrap libgcc and compiler-rt
the same way.
- Organize LLVM bintools as `bintools{-unwrapped,,NoLibc}` for
consistency with GNU Binutils and Apple's cctools.
- Do Android changes for all `llvmPackages` for consistency.
- Improve the way the default GCC and LLVM versions are selected.
The main thing was using `llvm_meta` in all versions.
Secondarily:
- libunwindx7: Forgot to split outputs
- libcxx{,abi} 12: Forgot to apply output-splitting patches.
- simplify `useLLVM` stdenv-switching logic.
- openmp always gets its own directory
treewide: Some LLVM / bootstrapping / cross cleanups especially for consistency
Should be fixed by #123886. Note that there could be similar regression for virtually everything that uses clang and LTO in nixpkgs, but I guess it is not that many derivations? |
|
For libxml2, maybe #123890 |
Having some difficulty verifying if that fixes
😕 |
I'm not getting that failure. (x86_64 NixOS, sandboxed) |
|
Nevertheless, the php issue doesn't seem affected by the change. |
|
Okay, good to know. I was trying to opposite direction next, cherry-pick libxml2 2.9.12 into Unfortunately, I'm again blocked by gnutls. 😕 I think it's actually an issue with my local qemu VM, that mysteriously hangs at various idle points, because the failures are random timeouts in tests. |
Conflicts: pkgs/development/tools/kubie/default.nix
|
I think the immediate course of action will be:
Release is scheduled to be done by next week. @grahamc for next release, we should really increase the x86_64-darwin compute going into ZHF, if they are going to be included in jobsets which will determine merge-ability :) |
|
I managed to resolve my VM issue and do some further testing. (Apparently, I have to run qemu with Curiously, I got two different results on Linux: |
|
Hmm, the subtlety for the second case, of just overriding the libxml2 build input, is whether it is also overridden for PHP itself. Overriding libxml2 for both PHP and the dom extension results in the same failure as on Hydra. So looks to me like it's definitely the libxml2 upgrade. |
Since 37194a3 llvmPackages*.bintools is a bintools-wrapper. Thus it only contains a wrapper for `as` and `ld`. This change makes sense, but causes regressions like this one. Since the buildStdenv uses the llvm bintool set including lld as a linker we can use the cc.bintools.bintools derivation to get all the tools we need. Technically we wouldn't need to set absolute paths as all tools are also added to PATH, but it doesn't hurt either.
[staging-next] firefox: take LLVM tools from buildStdenv
Conflicts: pkgs/development/tools/rust/cargo-expand/default.nix pkgs/tools/misc/blflash/default.nix
|
I made an attempt to fix the PHP issue upstream in php/php-src#7030. With that patch, the full |
|
I did the review report myself, and was able to build many of the "failed builds". I think this is fine to merge |
Conflicts: pkgs/tools/networking/xh/default.nix
|
waiting on eval to finish |
|
eval finished |
https://hydra.nixos.org/job/nixpkgs/staging-next/unstable#tabs-constituents (soon)
Should be the final staging-next for ZHF
Major areas of focus: llvm packages, aarch64-darwin support.
Previous Staging-next: #122068