stdenv: Nix-driven bootstrap of gcc #209870

ghost · 2023-01-09T12:14:08Z

✔️ Good to go.

Deferred cc-wrapper: replace ln -s $libgcc/lib/libgcc_s.so $lib/lib/ with -L${gccForLibs.libgcc}/lib" #221525
bootstrap-files allowedRequisites issue.
Make a "last call" for anybody to raise objections
all jobs pass on Hydra

Summary

By default, when you type make, GCC will compile itself three times. This PR inhibits that behavior by configuring GCC with --disable-bootstrap, and reimplements the triple-rebuild using Nix rather than make/sh.

Immediate Benefits

Allow gcc11 and gcc12 on aarch64 (without needing new bootstrapFiles)
Faster stdenv rebuilds: the third compilation of gcc (i.e. stageCompare) is no longer a drvInput of the final stdenv. This allows Nix to build stageCompare in parallel with the rest of nixpkgs instead of in series.
No more copying libgcc_s out of the bootstrap-files or other derivations
No more Frankenstein compiler: the final gcc and the libraries it links against (mpfr, mpc, isl, glibc) are all built by the same compiler (xgcc) instead of a mixture of the bootstrapFiles' compiler and xgcc.
No more static lib{mpfr,mpc,gmp,isl}.a hack
Many other small stdenv hacks eliminated
gcc and clang share the same codepath for more of cc-wrapper.

Future Benefits

This should allow using a foreign bootstrap-files so long as hostPlatform.canExecute bootstrapFiles.
This should allow each of the libraries that ship with gcc (lib{backtrace, atomic, cc1, decnumber, ffi, gomp, iberty, offloadatomic, quadmath, sanitizer, ssp, stdc++-v3, vtv}) to be built in separate (one-liner) derivations which inherit src; from gcc, much like WIP: GCC with separated runtime libraries #132343

Incorporates

Closes

Credits

This project was made possible by three important insights, none of which were mine:

@Ericson2314 was the first to advocate for this change, and probably the first to appreciate its advantages. Nix-driven (external) bootstrap is "cross by default".
@trofi has figured out a lot about how to get gcc to not mix up the copy of libstdc++ that it depends on with the copy that it builds, by moving the bootstrapFiles' libstdc++ into a versioned directory. This allows a Nix-driven bootstrap of gcc without the final gcc would still having references to the bootstrapFiles.
Using the undocumented variable user-defined-trusted-dirs when building glibc. When glibc dlopen()s libgcc_s.so, it uses a completely different and totally special set of rules for finding libgcc_s.so. This trick is the only way we can put libgcc_s.so in its own separate outpath without creating circular dependencies or dependencies on the bootstrapFiles. I would never have guessed to use this (or that it existed!) if it were not for a comment in guix which @Mic92 mentioned.

My own role in this PR was basically: being available to go on acoding binge at an opportune moment, so we wouldn't waste acrisis.

trofi · 2023-01-09T12:54:46Z

temporary kludge: disable mallinfo2

Sounds suspiciously familiar: https://trofi.github.io/posts/275-nixpkgs-bootstrap-deep-dive.html

trofi · 2023-01-10T07:24:20Z

Could you submit this as a standalone PR? My revert-mallinfo2.patch hack doesn't fix the problem on x86_64, but I think your solution does (currently checking).

Yeah, will do.

trofi · 2023-01-10T07:58:57Z

Could you submit this as a standalone PR? My revert-mallinfo2.patch hack doesn't fix the problem on x86_64, but I think your solution does (currently checking).

Yeah, will do.

Done as #210004

…so.1` After upgrading to a recent version of Nixpkgs (2023-04-18), the build broke with the following error: ... auto-patchelf: 6 dependencies could not be satisfied error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/lib/libphobos2.so.0.98.0 error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/bin/rdmd error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/bin/dub error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/bin/dustmite error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/bin/ddemangle error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/bin/dmd auto-patchelf failed to find all the required dependencies. ... After investigation, it turned out that the cuase was a recent [change in Nixpkgs][0] after which `libgcc_s.so` is no longer part of the `glibc` package: Before (nixpkgs @ 2022-03-30): > nix build --json 'github:NixOS/nixpkgs/710fed5a2483f945b14f4a58af2cd3676b42d8c8#glibc^out' \ | jq -r '.[0].outputs.out' \ | xargs -I{} find {} $ -type l -or -type f $ -name '*libgcc_s*' /nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libgcc_s.so.1 /nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libgcc_s.so After (nixpkgs @ 2023-04-18): > nix build --json 'github:NixOS/nixpkgs/555daa9d339b3df75e58ee558a4fec98ea92521e#glibc^out' \ | jq -r '.[0].outputs.out' \ | xargs -I{} find {} $ -type l -or -type f $ -name '*libgcc_s*' (no output) Instead, we should use `gccForLibs.libgcc` as it includes exactly what we need: > nix build --json 'github:NixOS/nixpkgs/555daa9d339b3df75e58ee558a4fec98ea92521e#gccForLibs^libgcc' \ | jq -r '.[0].outputs.libgcc' \ | xargs -I{} find {} $ -type l -or -type f $ -name '*libgcc_s*' /nix/store/5w5qpm9z3iyib615pdih6nvk9spv3jbv-gcc-12.2.0-libgcc/lib/libgcc_s.so.1 /nix/store/5w5qpm9z3iyib615pdih6nvk9spv3jbv-gcc-12.2.0-libgcc/lib/libgcc_s.so This is nixpkgs again @ 2023-04-18, this time using `gccForLibs.libgcc` instead of `glibc.out`. [`gccForLibs`][1] is essentially `gcc.lib`: * an alias to `stdenv.cc.cc` if the host and target are the same and are GNU or * an alias to `gcc.cc` when `stdenv` is LLVM based as then `stdenv.cc.cc` would refer to clang and the `lib` output point to libclang libs, which are very different from what we need. [0]: NixOS/nixpkgs#209870 [1]: NixOS/nixpkgs#91293

See: oxalica/rust-overlay#121 See: NixOS/nixpkgs#209870

ghost · 2023-06-30T19:52:24Z

This is the cause of

cross compiled binaries segfault on pthread_cancel(3) due to missing libgcc_s.so #240484

The fix is in

gccCrossStageStatic: enable dynamic libraries, rename it #238154

…so.1` After upgrading to a recent version of Nixpkgs (2023-04-18), the build broke with the following error: ... auto-patchelf: 6 dependencies could not be satisfied error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/lib/libphobos2.so.0.98.0 error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/bin/rdmd error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/bin/dub error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/bin/dustmite error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/bin/ddemangle error: auto-patchelf could not satisfy dependency libgcc_s.so.1 wanted by /nix/store/kl8bjrlmlzcjz47c0n6kjsj1yxi6zpqm-dmd-binary-2.098.0/bin/dmd auto-patchelf failed to find all the required dependencies. ... After investigation, it turned out that the cuase was a recent [change in Nixpkgs][0] after which `libgcc_s.so` is no longer part of the `glibc` package: Before (nixpkgs @ 2022-03-30): > nix build --json 'github:NixOS/nixpkgs/710fed5a2483f945b14f4a58af2cd3676b42d8c8#glibc^out' \ | jq -r '.[0].outputs.out' \ | xargs -I{} find {} $ -type l -or -type f $ -name '*libgcc_s*' /nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libgcc_s.so.1 /nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libgcc_s.so After (nixpkgs @ 2023-04-18): > nix build --json 'github:NixOS/nixpkgs/555daa9d339b3df75e58ee558a4fec98ea92521e#glibc^out' \ | jq -r '.[0].outputs.out' \ | xargs -I{} find {} $ -type l -or -type f $ -name '*libgcc_s*' (no output) Instead, we should use `gccForLibs.libgcc` as it includes exactly what we need: > nix build --json 'github:NixOS/nixpkgs/555daa9d339b3df75e58ee558a4fec98ea92521e#gccForLibs^libgcc' \ | jq -r '.[0].outputs.libgcc' \ | xargs -I{} find {} $ -type l -or -type f $ -name '*libgcc_s*' /nix/store/5w5qpm9z3iyib615pdih6nvk9spv3jbv-gcc-12.2.0-libgcc/lib/libgcc_s.so.1 /nix/store/5w5qpm9z3iyib615pdih6nvk9spv3jbv-gcc-12.2.0-libgcc/lib/libgcc_s.so This is nixpkgs again @ 2023-04-18, this time using `gccForLibs.libgcc` instead of `glibc.out`. [`gccForLibs`][1] is essentially `gcc.lib`: * an alias to `stdenv.cc.cc` if the host and target are the same and are GNU or * an alias to `gcc.cc` when `stdenv` is LLVM based as then `stdenv.cc.cc` would refer to clang and the `lib` output point to libclang libs, which are very different from what we need. [0]: NixOS/nixpkgs#209870 [1]: NixOS/nixpkgs#91293

nixos-discourse · 2024-08-06T21:53:00Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/why-does-the-nixos-infrastructure-have-to-be-hosted-in-a-centralized-way/46789/41

github-actions bot added the 6.topic: stdenv Standard environment label Jan 9, 2023

ghost mentioned this pull request Jan 9, 2023

stdenv: aarch64-linux: gcc9 -> gcc12 #207135

Merged

13 tasks