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.
Merge conflict in `pkgs/by-name/en/envision/package.nix` between efb2d2b815fe9f7d12f4aab42c83e759db5ec716 (staging) and b9d59c4515ea7cd4595d342c9d87877b544e6dbd+de7a60960219b303cc44ad446f9e7ddaf23b9944 (staging-next).
The build of glibcInfo has been broken since
d86588d230 (from NixOS/nixpkgs#357052).
The common derivation had a makeFlags added which the info derivation
was overriding. The manual says build targets should be put in
buildFlags instead of makeFlags anyways, and doing so removes the
conflict.
Maximilian Bosch