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)
`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)
This is not necessary (stdenv uses either buildCommand or buildCommandPath,
depending on what's available), but it is confusing since it's not explicitly
used and would not work if structuredAttrs is enabled.
This was part of the gnome2 package set, which is being removed. This is
likely to be removed soon as well for depending on GTK2, but for now we
can move it to by-name at the top level.
Qt version seems to work well
GTK3 version has bugs but can compile working executables at least
doublecmd and lazpaint and cudatext seem to be working, from the first glance
