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

This commit adds an option `disableGdbPlugin` which controls whether or not the plugin *for* GDB will be built. This plugin contains a copy of `gcc`. The configure flag that this option controls is called `--disable-libcc1`. This flag name is slightly confusing: it is used only by GDB (and apparently unmaintained), yet the flag name does not mention GDB. This is why the option name is different from the configure flag name. The primary motivation for this commit is to allow the following PR (which is not yet merged) to pass `--disable-libcc1` when building the final native (build=host=target) compiler as part of the stdenv bootstrap: NixOS/nixpkgs#209870 We need to `--disable-libcc1` in this scenario because gcc's build machinery links `libcc1` against the `libstdc++` that is part of the *compiler used to compile gcc*, rather than against the `libstdc++` that is built *by* gcc. In an FHS distribution this distinction is not terribly important because dynamically linked libraries are late-bound (ld.so resolution). However in nixpkgs this causes a reference back to the bootstrapFiles to leak all the way through to the final stdenv. More details can be found in the comment in `pkgs/stdenv/linux/default.nix` of the PR linked above. Co-authored-by: Sandro <sandro.jaeckel@gmail.com>

At least on armv7l-linux bootstrapTools fixed version of bits/statx.h breaks the header: NixOS/nixpkgs#209870 (comment) Drop the header along with other already cleaned ones.

@trofi

As suggested by @trofi here: NixOS/nixpkgs#209870 (comment) This should fix failures among packages which use gfortran: NixOS/nixpkgs#209870 (comment) https://hydra.nixos.org/build/215195834

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