This build was also broken by a libc const that isn't a number anymore
and thus can't be used at places where a constant value is needed:
automount.c:86:37: error: initializer element is not constant
Failing Hydra build: https://hydra.nixos.org/build/153253104
The issue was that `SIGSTKSZ` isn't an actual const anymore and thus
can't be used to define sizes of static variables such as
static char foo[SIGSTKSZ];
since this results in compiler errors such as
error: array bound is not an integer constant before ']' token
Fedora worked around this by hard-coding the value in `catch`. Since
this is mainly a testing-framework and there's no other fix for v1 - we
should eventually remove it entirely in favor of v2 anyways - I guess
this is a good-enough fix.
Failing Hydra build: https://hydra.nixos.org/build/152455108
This is a problem that seems to be related to the most recent `gdb`
update in staging from 10.2 to 11.1[1] where `gdb` started to fail
during build with the following message:
checking for stdlib.h... In file included from /nix/store/vf96x4h90fm7bwf5zvfx8zb82fm1p21j-glibc-2.34-5-dev/include/signal.h:328,
from ../../gnulib/import/signal.h:52,
from targ-map.c:7:
targ-map.c:412:17: error: initializer element is not constant
412 | { "SIGSTKSZ", SIGSTKSZ, TARGET_SIGSTKSZ },
| ^~~~~~~~
targ-map.c:412:17: note: (near initialization for 'cb_init_signal_map[18].host_val')
Since I couldn't find any patches in the upstream repo or for other
repos - according to Repology we seem to be the only distro trying to
ship `gdb-11` with `glibc-2.34` - so I found the culprit while bisecting
`gdb` which seems to be commit `a0e674c1`[2].
It seems as if the entire `sim/`-subtree is now built by default if
`--enable-targets=all` is set (which we do for cross debugging). However
it also generates a file called `targ-map.c` referencing `SIGSTKSZ`
assuming that it's const, although this is not the case anymore with
`glibc-2.34`[3].
Since I don't really understand, what precisely is going on in there and
there are no patches available I decided to switch back to the 10.2
behavior here and disable the feature by specifying `--disable-sim` as
configure flag.
Failing Hydra build: https://hydra.nixos.org/build/153893135
[1] 43b96f66ef
[2] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a0e674c1ce2c877426f8a861c5294c535c5d49e6
[3] see https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html
Rather than `$BASH`, `glibc` now hardcodes `/bin/bash` as
interpreter[1] in several scripts (including `ldd`).
This is a problem because relevant programs such as `ldd(1)` won't work
properly without this since we set `BASH` to `/bin/sh` to avoid
dependencies to the bootstrap tools for `bash` as runtime-dependency (since
NixOS doesn't have `/bin/bash`).
Considering that this was only done as an "improvement" to their
build-system and not because they wanted to use some bashisms here (the
variable was always called `BASH` and we still used `/bin/sh` anyways),
I'd consider this to be relatively safe.
[1] 5188a9d0265cc6f7235a8af1d31ab02e4a24853d
To quote the release-notes[1]:
> When _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined,
> PTHREAD_STACK_MIN is no longer constant and is redefined to
> sysconf(_SC_THREAD_STACK_MIN). This supports dynamic sized register
> sets for modern architectural features like Arm SVE.
This basically means that if the above applies, `#if PTHREAD_STACK_MIN > 0`
won't compile anymore because `PTHREAD_STACK_MIN` isn't a hard-coded
number, but `__sysconf (__SC_THREAD_STACK_MIN_VALUE)`[2].
The issue (for 1.69, 1.70, 1.72 - the other versions seem OK) was
reported upstream, but only for Solaris[3], however the corresponding
patches[4] seem to work as well for us.
Failing Hydra build: https://hydra.nixos.org/build/150926294
[1] https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html
[2] See `${pkgs.glibc.dev}/include/bits/pthread_stack_min-dynamic.h`
[3] https://github.com/boostorg/thread/issues/283
[4] https://github.com/conan-io/conan-center-index/pull/361
This "-D__nonnull\\(params\\)=" leads to a compilation failure in e.g.
the configure phase:
configure:21131: gcc -c -D__nonnull\(params\)= conftest.c >&5
<command-line>: warning: ISO C99 requires whitespace after the macro name
<command-line>: error: stray '\' in program
<command-line>: error: expected ',' or ';' before '(' token
<command-line>: error: stray '\' in program
According to the commit this isn't even needed on Linux.
I confirmed that this is an (expectable) glibc-2.34 thing by checking
that
* the issue doesn't occur with gcc 10/11 on a recent glibc-2.33 staging.
* the issue DOES occur in a docker container with Fedora rawhide (which
has glibc 2.34 and gcc 11).
Linking via `-lpthread` (or `-pthread`) is not needed anymore since
`glibc-2.34` since all the functionality is part of `libc.so.6` and
`libpthread.so.6` only exists for backwards-compatibility.
However, e.g. `gcc` (`libgomp` to be precise) expects a `libpthread.so`
to link against, otherwise the configure script will fail. As already
stated in the glibc release-notes itself, it is to expect that a lot
more applications will have issues with this, so I decided to re-add
`libpthread.so` as well.
For `librt.so.1`, the same thing is needed to make sure that Perl still
compiles:
/nix/store/d6y5r7m93x14bmgn2p75fannz39jz66f-binutils-2.35.1/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:490: ../../lib/auto/Time/HiRes/HiRes.so] Error 1
make[1]: Leaving directory '/build/perl-5.34.0/dist/Time-HiRes'
This fix is needed to work around linker-errors such as
undefined reference to `__libc_csu_fini'
which I got in almost every derivation which is part of stage2. The
reasoning behind this is that the startup-code was simplified[1] and
thus `__libc_csu_fini` doesn't exist anymore.
A workable solution is to use a newer libc which properly links in
stage3. And actually this seems expected given the rationale for stage3:
# Construct a third stdenv identical to the 2nd, except that this
# one uses the rebuilt Glibc from stage2. It still uses the recent
# binutils and rest of the bootstrap tools, including GCC.
So this patch basically overrides the libraries inside `gcc-unwrapped` -
which is basically the bootstrap tools and thus also contains the libc
used in stage3 - with the shared objects from the freshly built libc
from stage2.
[1] https://sourceware.org/pipermail/libc-alpha/2021-March/123079.html
Update version to 1.4.231.
Build 231 points to a specific commit from the 1.4.x branch adding many
fixes and improvements. Since this version is an unofficial release, add
an unstable prefix to the version string in Nixpkgs.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Signed-off-by: Franz Pletz <fpletz@fnordicwalking.de>
