The chain is the part of this package set that cannot be read off any one
file: four compilers, each a step further along, and two `libgcc`s either
side of the libc. Until now it was only recoverable by reading the
`overrideCC` call sites in order and reconstructing the argument.
Write it down once, as a table, next to why the cycle needs breaking at
all -- a libc's sources call into libgcc, and a libgcc that can use the
libc's threads needs the libc. Also record the two things that are easy
to get wrong and hard to notice: that the pre-libc stage is written down
in exactly one place (`binutilsNoLibc` carrying `preLibcHeaders` as its
`libc`), and that a libgcc built with `inhibit_libc` still compiles,
links and installs, just with pieces silently missing.
The per-wrapper comments shrink to what is local to each -- which stage it
is and what keeps the libc out -- since the chain-wide narrative now has
somewhere better to live.
Assisted-by: Claude Code (Claude Opus 5)
`--enable-clocale=gnu` was passed for every target. That selects
`config/locale/gnu`, the glibc locale model, whose
`ctype_members.cc` reads `__ctype_b` -- a glibc symbol. On any other
libc the build fails on the type the table is not:
ctype_members.cc:50:51: error: cannot convert 'const short unsigned int*'
to 'const std::ctype_base::mask*' {aka 'const unsigned int*'} in assignment
libstdc++ works this out for itself from the host triple, as it does for
the OS layer next door -- `configure.host:262` maps `linux-musl*` to
`os/generic` -- and the monolithic build passes no `--enable-clocale` at
all, leaving that to configure. Do the same here.
Verified by building the full cross toolchain, `stdenv.cc`, for
`aarch64-unknown-linux-musl`, which builds libstdc++ and previously
failed on exactly this.
Assisted-by: Claude Code (Claude Opus 5)
Two things a monolithic build does implicitly that the split set had
nobody to do.
Linking `libstdc++.so` with `g++` fails, because that driver implies
`-lstdc++` and the library being linked is the one that would provide it:
ld: cannot find -lstdc++: No such file or directory
`libstdc++-v3/src/Makefile.am` names the remedy where it defines
`CXXLINK`: use `gcc` as the C++ compilation driver, which the top level
arranges via `RAW_CXX_FOR_TARGET` -- `xgcc`, not `xg++`, plus
`-shared-libgcc` and `-nostdinc++`. Configured standalone there is no top
level to arrange it, so arrange it here. The C driver still compiles
`.cc` as C++ by extension; what it drops is the implicit `-lstdc++`.
`-shared-libgcc` restores the linkage `g++` would have chosen, and
`-nostdinc++` keeps already-installed C++ headers out of the build whose
purpose is to produce them.
`src/Makefile` also computes `LTLDFLAGS` by shelling out to
`$(top_srcdir)/../libtool-ldflags`, reaching out of `libstdc++-v3` into
the GCC top level. Our trimmed source tree never copied it, so the shell
reported `No such file or directory`, `LTLDFLAGS` came out empty, and
`LDFLAGS` was quietly dropped from every library link. Same failure mode
as the `gthr-default.h` bug: a file that exists only because a monolithic
tree has it, missing without anything treating its absence as an error.
Assisted-by: Claude Code (Claude Opus 5)
Two halves of how the compiler finds libstdc++.
The library was not on the link path. `wrapCCWith` was given
`libcxx = libstdcxx`, which tells cc-wrapper where the C++ headers live
but does not put the library where a GNU compiler looks, so every C++
link failed with `cannot find -lstdc++`. Add `-B${libstdcxx}/lib`, as
libgcc, libssp, libatomic and libgomp already are.
The headers had the opposite problem: found too eagerly, by the wrong
language. libstdc++ deliberately ships headers named after C headers --
`math.h`, `stdlib.h`, `complex.h`, `stdckdint.h`, `stdbit.h`,
`stdatomic.h`, `tgmath.h`, `fenv.h` -- whose purpose is to shadow the C
ones when compiling C++. Installed into `$dev/include` they shadowed
unconditionally, since `libcxx` is a propagated target-target dep of
cc-wrapper and the setup hook puts that directory on the **C** include
path of everything built with the compiler. Under C, libstdc++'s
`<stdckdint.h>` is an empty shell, so its functions vanish:
bash: braces.c: implicit declaration of function 'ckd_sub'
coreutils: randperm.c: implicit declaration of function 'stdc_bit_width'
Both build fine with monolithic GCC, whose libstdc++ headers live in
`include/c++/$ver` and are added by the g++ driver alone. Install them
into a sibling `include-cxx`, which keeps them off C's include path while
staying findable for C++; no version or target subdirectory is needed,
since the store path already separates one libstdc++ from another.
Assisted-by: Claude Code (Claude Opus 5)
One question in three places: which part of the split set carries the
target libc, and what happens where there is none yet.
The compiler was configured with
`--with-sysroot=${lib.getDev targetPackages.libc}`, so every libc change
moved `gcc-unwrapped` -- the most expensive thing here to rebuild, and
exactly the coupling this split exists to remove. cc-wrapper already
supplies the target libc, the same way the LLVM set leaves `clang`
carrying none. Measured with a behaviour-free libc change: before,
`gcc-unwrapped` moves, hours; after, `gcc-unwrapped` and `libgcc` are
byte-identical and only `libstdcxx` and the wrapper move, minutes.
libgcc is where the headers are wanted, and it wants them twice. First,
`gcc/configure` sets `inhibit_libc=true` when host != target and
`$target_header_dir/stdio.h` is absent, which makes `tsystem.h` skip
`<unistd.h>` and friends. That is fine for the generic sources and fatal
for the target-specific ones that need libc declarations, which fail as
`implicit declaration of function 'profil'` and the like.
`target_header_dir` comes from `--with-sysroot`, not `--with-headers`, so
point the sysroot pair at whichever libc the compiler carries -- read
off `stdenv.cc.libc`, which in the pre-libc build is `preLibcHeaders`,
the header-only package nixpkgs already keeps for this stage (NetBSD,
MinGW, Cygwin), and nothing at all elsewhere. Being headers-only, a libc
change still leaves the pre-libc libgcc byte-identical.
Reading it off the compiler rather than naming `preLibcHeaders` also
fixes glibc and musl, which matched no branch of `preLibcHeaders`, got no
sysroot at all, and so built their real libgcc with `inhibit_libc` set.
That is silent -- it compiles, links and installs cleanly, and
`_eprintf.o` simply comes out empty:
aarch64-unknown-linux-gnu libgcc.a
before 413014 bytes, `__eprintf` absent
after 415276 bytes, `__eprintf` present
The real libc is already an input to that build through `stdenv.cc`, so
naming it here adds no coupling. Dropping the flag instead was the other
option; NetBSD shows the cost, where all 334 libgcc compiles gain
`-Dinhibit_libc` and the same symbol disappears there too.
Second, `limits.h`. gcc's chains to the target libc's with
`#include_next`, and that is the right header to ship: it names no libc,
so it stays correct for whatever is on the include path later. Where the
compiler has a libc -- headers-only or real -- the chain resolves, and
must: those same sources want `PATH_MAX` from it. Where it does not, the
chain has nowhere
to land and even configure's `AC_PROG_CPP` probe fails, since it includes
`<limits.h>` precisely because that "exists even on freestanding
compilers", after which it falls back to `/lib/cpp` and reports that:
checking how to run the C preprocessor... /lib/cpp
configure: error: C preprocessor "/lib/cpp" fails sanity check
Only then, put gcc's own `glimits.h` earlier on the include path for this
build. That is the self-contained variant, the same file gcc installs
when configured against no libc. It is build-local: the compiler keeps
shipping the chained header.
Fixing the compiler instead is wrong, and glibc catches it at once --
`bits/stdlib.h:98: #error "Assumed value of MB_LEN_MAX wrong"` while
building libgomp. `limits.h` is the only header libgcc wanted on glibc
and musl, which is why this is one build-local include path rather than a
header package per libc.
Verified by building `stdenv.cc` for `aarch64-unknown-linux-gnu` and
`aarch64-unknown-linux-musl`, neither of which worked before;
`x86_64-unknown-netbsd`, whose bootstrap compiler carries
`preLibcHeaders`, uses those headers and carries no freestanding include
path.
Assisted-by: Claude Code (Claude Opus 5)
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)
The package set offered two compilers either side of a gap:
- `gccNoLibgcc` — no libgcc, no libc. Builds libgcc.
- `gccWithLibc` — libgcc *and* libc. Builds libssp and everything above.
Nothing in between, and the missing stage is the one a libc is compiled
with. A libc's own sources call into libgcc — 128-bit and soft-float
helpers, `__stack_chk`-adjacent bits, unwinder support — so
`gccNoLibgcc` cannot compile it. `gccWithLibc` obviously cannot either:
it is defined in terms of the libc that does not exist yet. Any platform
bringing up a new libc therefore has no compiler to express the step
with, and the bootstrap simply cannot be written down.
Add `gccWithLibgcc`: libgcc present, libc absent. `binutilsNoLibc` is
what enforces the second half — it supplies the header-only
`preLibcHeaders` rather than a real libc, so the derivation refers to no
libc at all and the dependency cycle stays broken. Verified on a cross
target: the wrapper's `orig-libc` is the headers package, and a
translation unit needing `__udivti3` compiles and links against libgcc.
This is additive; no existing derivation changes.
Assisted-by: Claude Code (Claude Opus 5)
A release tarball carries generated files that a git tree does not, and
two of those bit us.
`MD5SUMS` is generated when a tarball is rolled. Each sub-source
extractor asserted `[[ -f MD5SUMS ]]` before copying it, so every one of
them failed outright the moment `monorepoSrc` was a git tree:
unpacking source archive /nix/store/...-source
source root is source
<exit 1>
Copy it only when it is there.
The generated sources are the other half: a checkout lacks
`gengtype-lex.cc` and friends, which a tarball ships pre-built, so they
have to be regenerated. Take flex and bison as native inputs when
`fromVCS` says the source is a checkout.
Tarball builds are unaffected either way.
Assisted-by: Claude Code (Claude Opus 5)
GCC decides at configure time what its assembler and linker can do and
writes the answers into the compiler. A probe it cannot run is not an
error -- it silently records "no". We passed `--with-as` but put nothing
on `PATH`, so the probes had no tools to ask, and **31 capability macros**
came out wrong in the installed `auto-host.h`: `HAVE_GAS_HIDDEN`,
`HAVE_LD_PIE`, `HAVE_LD_RELRO_SUPPORT`, `HAVE_LD_NOW_SUPPORT`,
`HAVE_LTO_PLUGIN`, `HAVE_COMDAT_GROUP`, `HAVE_GAS_CFI_DIRECTIVE`,
`HAVE_AS_LEB128`, `HAVE_LD_EH_FRAME_HDR` and more. nixpkgs' hardening
flags were quietly inert, LTO unavailable, C++ without COMDAT.
`HAVE_GAS_HIDDEN` is how it surfaced: without it `-fvisibility=hidden`
is not rejected but becomes a no-op that merely warns, so every symbol
stays preemptible while GCC still emits direct `R_X86_64_PC32`
references, which the linker then rejects:
libc_pic.a(stats.pico): relocation R_X86_64_PC32 against symbol
`opt_stats_interval_opts' can not be used when making a shared object
Found on NetBSD, where it stops `libc.so` linking at all. Targets
matching configure's hardcoded `*-*-solaris2*` case escape it, which is
what made it look target-specific.
Put the unwrapped bintools on `PATH` via `depsBuildTarget` -- they run on
the build machine and act on target artifacts -- so the probes ask the
real tools. Unwrapped keeps the earlier decoupling: `as` and `ld` proper
carry no target-libc reference, unlike the bintools wrapper.
Drop `--with-as` rather than adding `--with-ld`. Those bake
`DEFAULT_ASSEMBLER`/`DEFAULT_LINKER` as absolute store paths, so the
driver runs exactly those binaries instead of deferring to the wrapped
ones. Finding them at use time is what the three `find_a_program`
patches are for: `PATH` was left to `execvp`, which matches `NAME` alone,
and `PATH` is exactly where we expose a cross toolchain under prefixed
names. They come from the posting to `gcc-patches`; the second needs a
`postFetch` tweak, being against trunk where one cast is spelled with the
C++ operator rather than `CONST_CAST`.
All three configurations were built and compared:
- `--with-as` only (before): 31 macros wrong, `libc.so` unlinkable
- `--with-as` + `--with-ld`: capabilities recovered, but ten probes
still fail, because probes need the rest of binutils on `PATH`, not
one absolute path
- `PATH` only (this): all 31 recovered, `DEFAULT_ASSEMBLER` and
`DEFAULT_LINKER` undefined, `-print-prog-name=as`/`ld` return bare
names, so the wrapper stays in charge
Assisted-by: Claude Code (Claude Opus 5)
Nothing could select the split GCC package set, so none of the fixes
below this commit were reachable from a normal build.
Add `useGccNG` alongside the existing `useLLVM`/`useZig`/`useArocc`
choices, and honour it where a compiler is picked: the cross stdenv takes
`gccNGPackages.gcc`, and `stdenvNoLibs`/`stdenvNoLibc` map to
`gccNoLibgcc` and `gccWithLibgcc`. That last pair is the point of the
split. Both currently fall back to `gccCrossLibcStdenv`, because the
monolithic compiler cannot distinguish them; `lib/systems/default.nix`
says as much next to `linker`, noting that we would like to choose the C
compiler and runtime library orthogonally but "due to the monolithic GCC
build we cannot actually make those choices independently". This is what
lifts that, the way the LLVM set already splits `clangNoCompilerRt` from
`clangNoLibc`.
`gccNGPackages` tracks `default-gcc-version` rather than naming a
release, so the split set and the monolithic `gcc` stay on the same one.
`useGccNG` defaults to `false` and no platform derives it, so no existing
build changes. Setting it on a platform spec is enough to exercise the
whole stack:
nix-build . -A stdenv.cc --arg crossSystem \
'{ config = "aarch64-unknown-linux-musl"; useGccNG = true; }'
The intent is to switch obscure low-tier platforms over to it soon --
NetBSD first -- so `ng` gets dogfooded somewhere the blast radius is
small. Those switches come separately.
Assisted-by: Claude Code (Claude Opus 5)
`libgcc` runs `gcc/configure` itself, to generate the makefile fragments
the split build has nobody else to produce. That configure identifies the
target assembler and linker from `AS_FOR_TARGET`/`LD_FOR_TARGET` and
probes them for capabilities.
`preConfigure` set those *after* assigning `AS=$AS_FOR_BUILD` and
`LD=$LD_FOR_BUILD`, deriving them with `$(basename $AS)`. The build
assignments stomp on the variables the target ones are read from, so it
took the basename of the *build* tools -- plain `as` and `ld` -- and
looked for them inside the *target* wrappers, which install
machine-prefixed names only. Neither path existed. Nothing about that is
target-specific; it catches every cross target.
`gcc/configure` does not treat it as an error: a probe it cannot run
records "no", so every `gcc_cv_as_*`/`gcc_cv_ld_*` capability came back
"no". The silently fatal one is `HAVE_LD_EH_FRAME_HDR`, which
`unwind-dw2-fde-dip.c` gates `USE_PT_GNU_EH_FRAME` on, leaving the
unwinder with only the `__register_frame` registry, which nothing
populates for normally linked objects. libgcc and libstdc++ still build,
link and install cleanly, and every C++ `throw` finds no FDE and calls
`std::terminate`.
Snapshot the target tool names before the `*_FOR_BUILD` assignments
clobber them. `CPP` is not always exported, so fall back to the
machine-prefixed name the wrappers install.
Assisted-by: Claude Code (Claude Opus 5)
Use an ordered list in the description of options created by
utils.mkStateRevisionOption instead of a table. The man page renderer
(for `man configuration.nix`) does not support generating tables, even
though the HTML renderer does.
