- `gccNGPackages.libbacktrace`: Remove, in favor of the `libbacktrace`
package in `pkgs/by-name`
- `stdenvNoCxx`: New, a compiler with a libc but no C++ standard library
- `libbacktrace`: Build with `stdenvNoCxx`, so `libstdc++` can link it
without a cycle
- `gccNGPackages.gcc`, `gccNGPackages.libgfortran`,
`gccNGPackages.libstdcxx`: Take `libbacktrace` as a build input and pass
`--with-system-libbacktrace`
That option is not upstream; it comes from a patch posted to gcc-patches[^1],
which we fetch from the archive rather than vendor.
One posting covers every component that links libbacktrace, so each
package filters it down to the files its own `src` carries, and leaves
out the generated files because we regenerate those locally anyway.
`gcc` and `libgfortran` were already using this `libbacktrace`, but by
faking up the sibling directory an in-tree build would have had --
archive, libtool archive and headers -- for the relative paths to resolve
against. Passing the flag lets that go.
Note that this means our libstdc++ is getting `std::stacktrace` support
for the first time; we were unwittingly excluding the vendored support.
Nothing failed, which is why it went unnoticed:
`--enable-libstdcxx-backtrace` defaults to `auto`, and `auto` means yes
wherever the library is hosted, so the feature was asked for. But the
probe that picks the object format runs `libbacktrace/filetype.awk`,
which was not among the files we copied, so it got nothing back, warned
"could not determine output file type", and quietly settled on
`enable_libstdcxx_backtrace=no`.
Note also that with this approach, a downstream `libbacktrace`
*cannot* be built by the regular `stdenv` with `useGccNG = true`,
because its symbols would conflict. We'll see whether that is acceptable
or not. If it isn't, we can still avoid vendoring, but we will need to
replicate the symbol renaming that GCC would have done externally.
[^1]: https://inbox.sourceware.org/gcc-patches/20260814013206.3818461-1-git@JohnEricson.me/
Assisted-by: Claude Code (Claude Opus 5)
The crt-building hack in `postPatch` does two things, both of which assume ELF:
- it forces `libgcc.a` to depend on `crti.o`/`crtn.o`. Those are an ELF
convention. PE/COFF targets have no such files, so the rule makes the
build assemble the generic ELF `config/i386/crti.S` with a PE
assembler, which fails with `junk at end of line`.
- it blanks `SHLIB_LC`, which for ELF is `-lc` and stands in the way of
linking `libgcc_s.so` before libc exists. On Cygwin and MinGW
`SHLIB_LC` is instead the list of system import libraries the DLL
genuinely needs, so blanking it drops real dependencies.
So apply it only on ELF.
That leaves the pre-libc stage on PE/COFF with no way to link a shared
`libgcc`: every symbol in a DLL has to resolve at link time, and the
libc's import library does not exist yet. Build only `libgcc.a` there --
which is all that stage is used for -- and let the shared library be
built as usual once the real libc is present. Which case applies is
read from `stdenv.cc.libc`, as everything else in this package is, with
headers-only stand-ins marking themselves via `passthru.headersOnly`.
ELF targets build the same thing as before but do not keep the same
derivation: `--enable-shared` is now stated outright where configure was
previously left to default to it. `libgcc` for `x86_64-unknown-netbsd`
gains that one flag and nothing else.
Assisted-by: Claude Code (Claude Opus 5)
We don't really want to share Nix logic with the monolithic GCC build,
as GCC NG is supposed to be unconstrained to go in different directions.
Inline `libgcc-buildstuff.nix` and read `hostPlatform` throughout.
Assisted-by: Claude Code (Claude Opus 5)
Guard the substituteInPlace that strips -mtls-dialect=gnu2 with
lib.optionalString so it only runs when the flag could actually
be present:
targetPlatform.isLinux && targetPlatform.isx86
&& lib.versionAtLeast (lib.getVersion clang) "19.1"
This matches the condition the cc-wrapper uses when adding the
flag, preventing breakage on Darwin and aarch64-linux where the
option does not exist in the wrapper scripts.
Assisted-by: OpenClaw (friendli/zai-org/GLM-5.2)
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)
