- Drop libSystem. It’s no longer needed. The SDK can be downloaded and
built with existing tools.
- Add jq and tapi. Adding these allows the stdenv bootstrap to stop
special-casing stage 0.
- Update tests for updated ld64. It handles code-signing properly, so
the signatures aren’t broken.
The bootstrap tools linker sometimes crashes when trying to link the
sqlite3 tests, which causes the bootstrap Python not to have the sqlite3
module. This causes the freezegun module to fail to build later in the
bootstrap. Using the 11.0 SDK fixes the problem.
Upstream Python supports building with a newer SDK and back-deploying,
so this change should not negatively affect users on pre-11.0 releases.
Change the adapter to add the requested SDK to the target’s build
inputs. Note that only the “11.0” (i.e., 11.3) and 12.3 SDKs are
supported. This adapter is retained for compatibility. The preferred way
to override the SDK is to add it to the appropriate inputs directly.
`${stdenv.cc.libc}/lib/libSystem.B.dylib` does not exist and not existed
for as long as I have used nixpkgs. Since `/usr/lib/libSystem.B.dylib`
is already linked via text-based stubs, continue relying on those.
While it would be nice if this could be split, there are too many
changes as part of the cleanup and improvements, including:
- Refactoring all propagated packages into functions that can be used to
ensure that packages are propagated only at the expected stages;
- Using a sanity-checking merge function to ensure that packages are
only propagated by one of the above functions;
- Reducing the number of Python builds during the bootstrap to one;
- Removing the extra sysctl stage;
- Using the LLVM bootstrap to build LLVM, clang, libc++, etc;
- Propagating llvmPackages_<version> in the final stdenv, so that
packages needing that version specifically don’t have to rebuild it;
- Bootstrapping with the new Darwin SDK; and
- Reducing the overall number of paths build during a bootstrap by ~33%.
After discussing on Matrix in the [#staging](https://matrix.to/#/#staging:nixos.org) room, I'm merging this as-is without waiting for changes to the `enableParallelBuilding = false;` line.
There are several in-the-wings PRs (one from @emilazy) that attempt to bring load-limit, which is a more sensible accounting of the work that a derivation is doing, into Nix itself. If and when that lands, we'll be able to just set `enableParallelBuilding = true;` again, without any specific casing around the `NIX_BUILD_CORES` stdenv variable.
Currently stdenv requires Bash 4.x that was released in 2009. This
change bumps the required version to Bash 5.x (2019, 5 years ago).
See https://mywiki.wooledge.org/BashFAQ/061 for more details.
Using a relatively modern Bash version allows us to rely on newer
features (e.g. ${var@a}) and remove workarounds for older quirks (e.g.
https://stackoverflow.com/a/7577209, “old bash empty array problem”).
Note that many setup hooks are using features added after 4.0 version,
e.g. makeWrapper uses ${var@Q} from 4.4, but some even require >5.0,
e.g. cargoBuildHook uses ${var@U} from 5.1.
For a long time, we've had `crossLibcStdenv`, `*Cross` libc attributes,
and `*bsdCross` pre-libc package sets. This was always bad because
having "cross" things is "not declarative": the naming doesn't reflect
what packages *need* but rather how we *provide* something. This is
ugly, and creates needless friction between cross and native building.
Now, almost all of these `*Cross` attributes are gone: just these are
kept:
- Glibc's and Musl's are kept, because those packages are widely used
and I didn't want to risk changing the native builds of those at this
time.
- generic `libcCross`, `theadsCross`, and friends, because these relate
to the convolulted GCC bootstrap which still needs to be redone.
The BSD and obscure Linux or freestnanding libcs have conversely all
been made to use a new `stdenvNoLibc`, which is like the old
`crossLibcStdenv` except:
1. It usable for native and cross alike
2. It named according to what it *is* ("a standard environment without
libc but with a C compiler"), rather than some non-compositional
jargon ("the stdenv used for building libc when cross compiling",
yuck).
I should have done this change long ago, but I was stymied because of
"infinite recursions". The problem was that in too many cases we are
overriding `stdenv` to *remove* things we don't need, and this risks
cyles since those more minimal stdenvs are used to build things in the
more maximal stdenvs.
The solution is to pass `stage.nix` `stdenvNoCC`, so we can override to
*build up* rather than *tear down*. For now, the full `stdenv` is also
passed, so I don't need to change the native bootstraps, but I can see
this changing as we make things more uniform and clean those up.
(adapted from commit 51f1ecaa59)
(adapted from commit 1743662e55)
This change switches the xar package from unmaintained fork of the
original project to the Apple Open Source tarball. See also
https://repology.org/project/xar/versions
Since the package is essentially rewritten from scratch, we take an
opportunity and move it to pkgs/by-name/xa/xar (formatted with nixfmt).
We also remove Windows from the supported platforms because even before
this change pkgsCross.mingwW64.xar failed with
xar> configure: error: can not detect the size of your system's uid_t type
The previously used pattern was introduced in #318614, but technically
leaked the default flags into the global scope. While this would
probably not make much of a practical difference, making concatTo
support default values is a much cleaner approach.
