Build the llvm support libraries (libcxx, libcxxabi) from scratch
without using the existing llvm libraries. This is the same spirit and
similar implementation as the "useLLVM" bootstrap in llvm package
sets. Critically it avoids having libcxxabi provided by the cc-wrapper
when building libcxx, which otherwise results in two libcxxabi
instances.
$ otool -L /nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.dylib
/nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.dylib:
/nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/nix/store/gmpwk5fyp3iasppqrrdpswxvid6kcp8r-libc++abi-7.1.0/lib/libc++abi.dylib (compatibility version 1.0.0, current version 1.0.0)
/nix/store/3hn7azynqgp2pm5gpdg45gpq0ia72skg-libc++abi-7.1.0/lib/libc++abi.dylib (compatibility version 1.0.0, current version 1.0.0)
/nix/store/1nq94scbxs6bk7pimqhvz76q6cfmbv97-Libsystem-osx-10.12.6/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
Additionally move some utilities (clang, binutils, coreutils, gnugrep)
to the stage layers so they can be replaced before the final
stdenv. This should cause most of stage4 to be built from the
toolchain assembled as of stage3 instead of the bootstrap toolchain.
This new version has tapi support, which is needed to build the new
stubs based libSystem, etc. and Big Sur support.
You can verify the provenance of these yourself by checking Hydra here:
https://hydra.nixos.org/build/128192471
This reverts commit c778945806b44d46ec16bc4302e7e7163e6bab97.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
I'm sorry; I didn't notice it contained staging commits.
This reverts commit 17f5305b6c20df795c365368d2d868266519599e, reversing
changes made to a8a018ddc0a8b5c3d4fa94c94b672c37356bc075.
The Rust `cc` crate started running `xcrun` when SDKROOT is defined:
a970b0ab0b
Consequently, building crates that use newer versions of the `cc`
crate fail, because xcrun is not available in pure build environments.
This was initially introduced in 92188d9d1751892ddbf8913da73dfc150d18fadb,
not clear how relevant this still is but i686 isn't supported anymore so
disable it explicitly.
Fixes#21629
Passing these extra linker flags removes both the semi-random uuid
included in most binaries as well as making the sdk version consistent
instead of based on the current os version.
Load command 8
cmd LC_UUID
cmdsize 24
uuid 70FAF921-5DC8-371C-B814-4F121FADFDF4
Load command 9
cmd LC_VERSION_MIN_MACOSX
cmdsize 16
version 10.12
sdk 10.13
The -macosx_version_min flag isn't strictly necessary since that's
already handled by MACOSX_DEPLOYMENT_TARGET.
- Replaced python override from the final stdenv, instead we
propagate our bootstrap python to stage4 and override both
CF and xnu to use it.
- Removed CF argument from python interpreters, this is redundant
since it's not overidden anymore.
- Inherit CF from stage4, making it the same as the stdenv.
Adds the static overlay that can be used to build Nixpkgs statically.
Can be used like:
nix build pkgsStatic.hello
Not all packages build, as some rely on dynamic linking.
crossOverlays only apply to the packages being built, not the build
packages. It is useful when you don’t care what is used to build your
packages, just what is being built. The idea relies heavily on the
cross compiling infrastructure. Using this implies that we need to
create a cross stdenv.
02c09e01712ce0b61e5c8f7159047699a434f7fc (NixOS/nixpkgs#44558) was reverted in
c981787db951afb11c1328461df82d4277ebec07 but, as it turns out, it fixed an issue
I didn't know about at the time: the values of `propagateDoc` options were
(and now again are) inconsistent with the underlying things those wrappers wrap
(see NixOS/nixpkgs#46119), which was (and now is) likely to produce more instances
of NixOS/nixpkgs#43547, if not now, then eventually as stdenv changes.
This patch (which is a simplified version of the original reverted patch) is the
simplest solution to this whole thing: it forces wrappers to directly inspect the
outputs of the things they are wrapping instead of making stdenv guess the correct
values.
This accidentally added some unwanted dependencies on the bootstrap
tools, and I don't have time to fix before I go on vacation, so I'm
backing it out until I have time to address it properly.
This reverts commit dc5c68a7bb03e8807f8ab8ad30e5eb11d1f29302.
LTO is disabled during bootstrap to keep the bootstrap tools small and
avoid unnecessary LLVM rebuilds, but is enabled in the final stdenv
stage and should be usable by normal packages.
