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 fixes were backported from glibc master and had some slight
conflicts.
0001-resolv-Check-for-inet_ntop-failure-in-ns_sprintrrf.patch was
backported to avoid having to modify the fix for CVE-2026-6238.
The `gettext` package is required in order to build and install the libc
message catalogs.
Previously, glibc was falling back to the C locale, even though the
default locale has been changed (e.g. to de_DE.UTF-8):
```
rm: das Entfernen von 'file' ist nicht möglich: No such file or directory
```
With this change, the whole string will be translated to the desired
locale:
```
rm: das Entfernen von 'file' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
```
Signed-off-by: David Wronek <david.wronek@mainlining.org>
The string returned by confstr(_CS_PATH)[*1], which is also the
output of the command 'getconf PATH'[*2], contains a default path
that is guaranteed to find (at least) all POSIX standard utilities.
The current value is:
/run/current-system/sw/bin:/bin:/usr/bin
The default profile binaries directory is not in it. This is a problem
because the default NixOS installation lacks several mandatory standard
POSIX utilities. The command recommended by the system's error message
for a missing command to install a missing package foo is 'nix-env -iA
nixos.foo'. When this is done as root, the corresponding binaries are
installed for all users in /nix/var/nix/profiles/default/bin.
This commit fixes these problems as follows:
pkgs/development/libraries/glibc/fix_path_attribute_in_getconf.patch:
- CS_PATH: Add default profile path '/nix/var/nix/profiles/default/bin'
at the end.
- Retain /bin:/usr/bin; it is necessary for third-party sytems that use
nixpkgs, linking against the nixpkgs version of glibc. It is retained
*before* the profile directory to avoid overriding native system
utilities on these systems (at least those that in fact store them in
/bin and /usr/bin).
[*1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/confstr.html
[*2] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/getconf.html
Fixes: https://github.com/NixOS/nixpkgs/issues/65512
The darwin-cross-build.patch failed to apply when cross-compiling glibc.
Regenerate the patch against glibc 2.42 sources. Also extend the
patch to cover the 'check xcheck test' target which was previously
unpatched but needs the same ulimit and AR fixes for consistency.
Tested: nix build --file . pkgsCross.aarch64-multiplatform.glibc
Tested: nix build --file . pkgsCross.gnu64.glibc
Creating the build directory in `..` may be OK in a sandbox, but this
makes it unnecessarily annoying when trying to work with this in a
source-checkout.
Hence, move the `build/` directory into the source tree.
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>
This was originally turned off in #245360 because the approach was
non-reproducible, i.e. all N concurrent jobs were racing to update
`locale-archive`.
glibc's localedef allows to separate the build from the install, i.e.
`localedef --no-archive` allows to only perform the build of the locale
which can be parallelized again. After that, a single process adds all
newly built locales into the archive.
This isn't supported by the Makefiles in upstream glibc yet[1], hence
the additional patches.
For me, this reduces the build-time of `pkgs.glibcLocales` from ~7min to
slightly under 1min.
[1] https://sourceware.org/pipermail/libc-alpha/2025-October/170803.html
To quote `getenv(3)`:
> The GNU-specific secure_getenv() function is just like
> getenv() except that it returns NULL in cases where "secure
> execution" is required.
One of these cases is running in setuid mode. In this case, one could
make `sudo` load an arbitrary file as locale archive by modifying the
LOCALE_ARCHIVE env variable accordingly.
After consultation with the security team we came to the conclusion that
this is not exploitable by itself since it'd need another issue that
can be triggered by a maliciously crafted locale archive. Since this is
a valid issue nonetheless[1], I decided to fix it, but go through the
normal PR & staging lifecycle.
This patch also adds another fallback to
`/run/current-system/sw/lib/locale/locale-archive`: otherwise `sudo`
would fail to load any locale archive since that would be in
LOCALE_ARCHIVE/LOCALE_ARCHIVE_2_27 and thus setuid programs would
regress on translated output.
Thank you to Elliot Cameron for reporting this.
[1] glibc's internal environment filtering also prevents setuid
processes to use certain locale settings from the environment
such as LOCPATH.
Addresses further comments in #347965
On a Ubuntu machine with only C.utf-8 installed, you'd still get
perl: warning: Setting locale failed
since C.utf-8 is installed into `/usr/lib/locale` directly rather than
the archive.
`glibc` will first try to find a locate in the archive[1] and then fall
back to `lib/locale`[2]. This means that Ubuntu applications still find
C.utf-8 since its glibc finds it in `/usr/lib/locale`. However, Nix
built applications don't since they fall back to the system-wide archive
in `/usr/lib/locale/locale-archive`.
This patch changes our glibc to do the same what Ubuntu does: C.utf-8 is
installed into `$out/lib/locale`. If the systemd-wide locale archive
doesn't have C.utf-8, glibc now falls back to looking in
`$out/lib/locale`.
I confirmed on an Ubuntu 24.04 VM with empty locale archive that a
`cowsay` built on this branch falls back to `$out/lib/locale`:
/* exists, but empty */
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
[...]
/* fallback */
openat(AT_FDCWD, "/nix/store/vckzn6k0648yas09c58aq05bav82l46x-glibc-2.40-66/lib/locale/C.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3
I checked that this doesn't have obvious regressions on NixOS by
building the synapse test on this branch since synapse explicitly
depends on C.utf8 in PostgreSQL.
[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/findlocale.c;h=e5e2bd3974fe4fd31ae3567d411f1f84dccf8573;hb=HEAD#l152
[2] https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/findlocale.c;h=e5e2bd3974fe4fd31ae3567d411f1f84dccf8573;hb=HEAD#l167
This change enables static compilation with glibc in a multilib setup. For
building a nix shell the output can now be referenced as follows:
devShells.default = pkgs.mkShell {
packages = [
pkgs.glibc_multi.static
];
};
In the implementation I was forced to make two design decisions:
1. The directory `$static/lib64` has to be a "real" directory and not a symlink.
Otherwise, the path to this directory is not added to $NIX_LDFLAGS, which in
turn causes the files to not be visible to gcc and ld during the build
process (for details see `pkgs/build-support/bintools-wrapper/setup-hook.sh`
line 16).
2. The directories `$static/lib` and `$static/lib64` have to contain symlinks
to both the files used for static and for dynamic linking (i.e. the outputs
of `static` and `out` of the 32 and 64 bit variant of glibc). Without this,
dynamic linking still works, however the resulting binaries will segfault.
