The libc bootstrap had every stage except the last. `gccNoLibgcc` builds
libgcc, `gccWithLibgcc` builds the libc with it — and then nothing goes
back to rebuild libgcc now that the libc exists. So the only libgcc
anyone ever got was the one from before there was a libc, which is
necessarily single-threaded: `gthr-posix.h` includes `<pthread.h>`
unconditionally, and at that point there is no libc to provide it.
`libstdcxx` above it assumed `posix` regardless, so the two disagreed by
construction — the unwinder's registry locking compiled away to nothing
underneath a `libstdc++` handing out `std::thread`.
Add the last stage the way the LLVM package set does with
`compiler-rt-no-libc` and `compiler-rt-libc`: instantiate the same
package twice. `libgcc-no-libc` is the existing one and now feeds only
the three bootstrap compilers. `libgcc-libc` is built after the libc, by
a new `gccWithLibcAndBasicLibgcc` — real libc, bootstrap libgcc — and is
what `libgcc` resolves to for any platform that has a libc.
Nothing is passed to the package to say which of the two it is. The
distinction is the compiler it is handed, exactly as in the LLVM set:
`gccNoLibgcc` is wrapped with `binutilsNoLibc`, whose `libc` is
`preLibcHeaders` -- the header-only stand-in, or nothing at all on
platforms without one -- and `wrapCCWith` defaults a wrapper's `libc` to
its bintools'. So the package reads `stdenv.cc.libc` and needs no
bootstrap flag of its own.
Which threading model is available is a property of the libc, so the libc
declares it as `passthru.threadModel` and `libgcc` reads it from there.
That is what makes the pre-libc build single-threaded without being told
to be: a headers-only package declares no `threadModel`, a real libc
does.
`libstdcxx` in turn takes both the model and the generated
`gthr-default.h` from `libgcc`, replacing a `$CXX -v` probe that asked
the compiler — which in this package set is configured separately from
libgcc and so answers for the wrong component. Platforms that declare
nothing keep the single-threaded model they already had.
The second libgcc is also the first one that can be shared. Previously
only the static library was built, and the compiler was configured
`--disable-shared` for every target, which is compiled into the driver's
specs, so it named bare `-lgcc` and never `-lgcc_s`:
$ x86_64-unknown-netbsd-g++ -### eh.cc
collect2 ... -lstdc++ -lm -lgcc -lc -lgcc
Both halves have to move together. Build the shared library without
changing the specs and the unwinder leaves `libgcc.a` while the specs
still name it:
libgcc.a _Unwind_RaiseException: absent
libgcc_eh.a _Unwind_RaiseException: present
libgcc_s.so.1 _Unwind_RaiseException: present
so every throwing C++ program fails to link and `rustc` fails on
`-lgcc_s` outright. Either standard arm would do, `-lgcc_s -lgcc` shared
or `-lgcc -lgcc_eh` static; the halves disagreeing is what breaks.
`--disable-shared` was passed to libgcc with the comment "Do not have
dynamic linker without libc". That does not hold: the monolithic build
ships `libgcc_s` even from its *nolibc* cross stage, and the result needs
nothing at run time --
$ readelf -d .../nolibc-gcc-15.3.0-libgcc/.../libgcc_s.so.1
0x...0e (SONAME) Library soname: [libgcc_s.so.1]
(no NEEDED entries at all)
What genuinely blocks it is libgcc's own makefile: `SHLIB_LC` defaults to
`-lc`, so the `libgcc_s.so` rule links against a libc that does not exist
yet and fails with `cannot find -lc`. The monolithic build clobbers that
variable -- see `common/libgcc-buildstuff.nix` -- so reuse that helper
rather than reinventing it. On the compiler side the flag derives from
`hasSharedLibraries`, as the monolithic build does, so a target genuinely
without shared libraries keeps the old behaviour; it is spelled
`enableTargetShared` there because it describes the target's libgcc
rather than anything about the compiler being built.
Verified on `x86_64-unknown-netbsd`, where `libgcc_s.so.1` and the
`GROUP ( libgcc_s.so.1 -lgcc )` script now appear in the output, and by
building `stdenv.cc` for `aarch64-unknown-linux-gnu` and
`aarch64-unknown-linux-musl`.
Assisted-by: Claude Code (Claude Opus 5)
this creates some eval errors that will be fixed in the next commit
done with the following script:
```fish
\#!/usr/bin/env fish
set packagesjson (nix eval --impure --json --expr '
let
lib = import ./lib;
in
import pkgs/servers/x11/xorg/default.nix (lib.mapAttrs (
name: _:
if name == "lib" then
lib
else if name == "config" then
{ allowAliases = false; }
else
name
) (__functionArgs (import pkgs/servers/x11/xorg/default.nix))) { }
' | jq)
set one (grep '^ [A-Za-z0-9_-]*$' pkgs/servers/x11/xorg/default.nix | string trim | string replace -r '$' Z | sort | string sub -e -1)
set two (grep '^ [A-Za-z0-9_-]* = [A-Za-z0-9_-]*;$' pkgs/servers/x11/xorg/default.nix | cut -d= -f1 | string trim | string replace -r '$' Z | sort | string sub -e -1)
for arg in $one $two
set oname $arg
set nname (echo $packagesjson | jq -r .$oname)
if test $nname = null
echo (set_color red)warn:(set_color normal) unknown package xorg.$oname >&2
continue
end
echo $oname "->" $nname
# replace basic xorg.$name references
for file in (rg -F "xorg.$oname" --files-with-matches pkgs)
# special cases
sd -F "$oname = xorg.$oname;" "$nname = $nname;" $file
# replace
sd -F "xorg.$oname" "$nname" $file
# fixup function arguments
# prevent duplicate function args
if grep -E " ($oname|$nname),\$" $file >/dev/null
continue
end
if grep 'xorg\..' $file >/dev/null # case1: there is more so we can't just remove the function arg
if grep ' xorg,$' $file >/dev/null
sd ' xorg,$' " xorg,
$nname," $file
else if grep ' xorg ? .*,$' $file >/dev/null
sd 'xorg( ? .*),$' "xorg\$1,
$nname," $file
else
sd -F 'xorg,' "$nname,
xorg," $file
end
else # case there is no more xorg..* so we can just replace the function arg
sd 'xorg(| ? .*),.*$' "$nname," $file
end
end
end
nix fmt
```
This commit was created by a combination of scripts and tools:
- an ast-grep script to prefix things in meta with `lib.`,
- a modified nixf-diagnose / nixf combination to remove unused `with
lib;`, and
- regular nixfmt.
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
