glibc 2.42→2.43 + C23-const FTBFS fixes (make stack + gcc)#238
glibc 2.42→2.43 + C23-const FTBFS fixes (make stack + gcc)#238bryan-minimal wants to merge 11 commits into
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThis PR updates build inputs and build flags: it bumps binutils to 2.46.1, bumps glibc to 2.43 (each with updated sha256), and adds a GCC build workaround that appends -Wno-error=discarded-qualifiers to CFLAGS/CXXFLAGS and propagates it to target flags. ChangesBuild inputs and build-script changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
The base-soup rebuild recompiles gcc-15.2.0 against the new glibc 2.43 headers, which implement ISO C23 const-preserving string macros (strchr et al. now return `const char *` for a `const char *` input). gcc-15.2.0 predates this, so libgomp/affinity-fmt.c (`char *q = strchr(p+1,'}')`) discards const and fails -Werror=discarded-qualifiers — the FTBFS the buildbot hit. The pointer is only used for `q - p`, never written, so it's a source-pedantry mismatch, not a runtime bug. Downgrade only that single warning (everything else stays -Werror) via CFLAGS_FOR_TARGET (the documented knob for target libs like libgomp) + CFLAGS, for gcc's own build only — the shipped compiler is byte-identical. Interim escape hatch; gcc-16.1.0 fixes this upstream and builds cleanly against glibc 2.43 (LFS pairs them with no workaround), so the clean follow-up is bumping gcc to 16. This is the same C23 wave hitting the whole ecosystem (openssl, grub, libevent, ...). Refs in build.sh. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Added: gcc glibc-2.43 build fix (commit 4cf505f)The first buildbot run failed building gcc-15.2.0 against the new glibc 2.43 headers — not glibc/binutils themselves. glibc 2.43 implements ISO C23 const-preserving string macros: This is the same C23 wave hitting the whole ecosystem right now (openssl, grub, libevent, criu, …) — a known, documented event, not anything specific to us. Fix here (interim, surgical): Clean follow-up: bump gcc → 16.1.0, which fixes this upstream and builds against glibc 2.43 with no workaround (LFS pairs them directly). That retires the band-aid; tracked separately as it's a major-version migration. Refs are also inline in |
🚧 Moved to draft — needs a team decision on the glibc-2.43 C23 waveSecond buildbot run got past gcc but then libxcrypt failed with the identical pattern: So this is confirmed fleet-wide, not a gcc one-off (see the previous comment for root cause: glibc 2.43's ISO C23 const-preserving string macros). Patching package-by-package is whack-a-mole, and gcc 16.1.0 would not help — it only fixes gcc's own source, not libxcrypt/openssl/grub/etc. The systematic fix: one line in the shared make harnessThe flags that land after each package's # harnesses/make/harness.ncl:9
CFLAGS = "-O2 -pipe -gno-record-gcc-switches",Because these are appended last on every compile (confirmed in libxcrypt's command line: - CFLAGS = "-O2 -pipe -gno-record-gcc-switches",
+ CFLAGS = "-O2 -pipe -gno-record-gcc-switches -Wno-error=discarded-qualifiers",gcc has a custom Why this is safe (but is a band-aid)
Decision for the team
My recommendation: the global Refs: glibc 2.43 C23 const macros · GCC CFLAGS_FOR_TARGET docs · LFS GCC-16.1.0 |
…2.43 C23 rebuild glibc 2.43's ISO C23 const-preserving string macros (strchr/strstr/memchr/... return `const char *` for const input) cause an ecosystem-wide -Werror=discarded-qualifiers FTBFS wave. The make stack's shared CFLAGS land after each package's own -Werror on the compile line, so appending the downgrade here fixes the whole make/autotools fleet in one place. Interim until a gcc-16 bump (which fixes it upstream). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ires gcc/build.sh Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…TBFS
libxcrypt has a hand-written build.sh that *assigns* CFLAGS (not the make
stack), so the stacks/make/stack.ncl fleet lever from this PR can't reach it.
Its crypt-{gost,sm3}-yescrypt.c assign const-qualified strchr() results to a
plain char*, tripping libxcrypt's own configure-enabled -Werror under glibc
2.43's ISO C23 const-preserving string macros. Downgrade only that one warning,
appended after -Werror so the later flag wins.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
elfutils hardcodes CFLAGS in its build.sh (bypasses the make stack) and defaults -Werror on. glibc 2.43's ISO C23 const-preserving bsearch/strchr-family lookups discard const into plain pointers (libcpu/riscv_disasm.c known_csrs bsearch), tripping -Werror=discarded-qualifiers. elfutils is notorious for multiple distinct -Werror trips across toolchain bumps, so use its own --disable-werror off-switch rather than chase warnings one flag at a time. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…disable-werror unrecognized) elfutils' configure has no --disable-werror in this version (it warned 'unrecognized options: --disable-werror' and kept -Werror on, so the C23 discarded-qualifiers trip in libcpu/riscv_disasm.c persisted). Use the same surgical CFLAGS flag as libxcrypt instead: automake emits $(AM_CFLAGS) $(CFLAGS), and elfutils' -Werror lives in AM_CFLAGS, so a -Wno-error in CFLAGS lands after it on the compile line and wins. The whole libelf tree compiled clean before the single trip, so the one warning is the only break. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
strace hardcodes CFLAGS in build.sh (bypasses make stack) and self-enables -Werror. glibc 2.43's ISO C23 const-preserving bsearch returns const for a const arg; src/ioctl.c assigns it to a plain pointer (iop = bsearch(..., ioctlent, ...)). Downgrade only that warning, appended after strace's -Werror on the compile line so the later flag wins. Same glibc-2.43 C23 class as #238. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…reads collision or-tools FetchContent's SCIP v10.0.0, which bundles tinycthread (a C11 <threads.h> shim doing `#define once_flag pthread_once_t`). glibc 2.43 surfaces its native once_flag/call_once into SCIP's TU, so that macro corrupts glibc's `typedef __once_flag once_flag;` into a pthread_once_t redefinition -> hard "conflicting types" FTBFS (not the -Werror class; -Wno-error can't help). or-tools 9.15 is already the latest release and pins current SCIP, so no version bump escapes it. or-tools hard-FORCEs SCIP TPI=tny in its bundled cmake, so a -DTPI=... is overridden. sed the forced TPI to omp before cmake: SCIP uses its OpenMP task interface (no tinycthread), staying parallel + THREADSAFE (SCIP auto-forces THREADSAFE on for non-none TPI). libgomp is present from gcc. A grep guard fails the build loudly if upstream renames the line. Leaf package (nothing depends on it) but in the glibc closure, so it must build. glibc-2.43 class, #238. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
What
glibc 2.42 → 2.43, plus the C23-const FTBFS levers needed for the rebuild. Reshaped to glibc-only (binutils 2.46.1 already landed separately on main, so it's dropped here) and rebased onto current main (picks up the harnesses →
stacks/migration).Why the two FTBFS fixes ride along
glibc 2.43 implements ISO C23 const-preserving string macros —
strchr/strrchr/strstr/memchr/etc. now returnconst char *for aconst char *argument. Pre-C23 code assigning the result to a plainchar *trips-Werror=discarded-qualifiersand FTBFS. This is an ecosystem-wide wave (gcc/libgomp, libxcrypt, openssl, grub, …), so two distinct levers — and they are NOT the same kind of fix:stacks/make/stack.ncl(fleet-wide, durable) — append-Wno-error=discarded-qualifiersto the shared make-stack CFLAGS. It lands after each package's own-Werror(later flag wins), downgrading that one warning across the whole make/autotools fleet.packages/gcc/build.sh(gcc-only, interim) — gcc-15.2.0 has its own build.sh (doesn't use the make stack) and its libgomp source hits the same break, so the downgrade goes in viaCFLAGS_FOR_TARGET.packages/gcc/build.sh). Every other C program in the fleet still trips the same break under any gcc against glibc 2.43, because the language semantics are unchanged. Lever #1 stays until either the ecosystem adopts C23-compatible source or we switch it to-std=gnu17(restores the C17 prototypes sostrchrreturnschar *— no warning at all, but a broader language-standard change). That-Wno-errorvs-std=gnu17choice is the toolchain-policy call this is parked on.Changes
packages/glibc/build.ncl— 2.42 → 2.43 (+ sha256)stacks/make/stack.ncl— fleet-wide-Wno-error=discarded-qualifiers(durable)packages/gcc/build.sh— same downgrade viaCFLAGS_FOR_TARGETfor gcc's own build (interim, retired by gcc-16)Status
Draft — toolchain-policy change (touches every C build). glibc 2.43 clears the glibc CVE backlog (CVE-2025-15281 + CVE-2026-5450 CRIT, etc.).
🤖 Generated with Claude Code