Pin a glibc sysroot in the toolchain, so the bundle's floor is built rather than patched #71

New issue

Open

opened 2026-09-06 17:30:16 +00:00 by bcox · 0 comments

bcox commented

2026-09-06 17:30:16 +00:00

Owner

The plugin GUI stage made the bundle's glibc floor visible: linking ImGui and libX11 pulled symbol versions (sqrtf/acosf @2.43, _inet*_chk @2.42) newer than Flatpak Bitwig's runtime glibc, and the bundle stopped loading in the DAW it is developed against.

The stopgap that shipped with the GUI branch pins the floor at 2.38 by hand: .symver bindings for the math pair, -U_FORTIFY_SOURCE on libx11, and //plugin:glibc_floor_test, which parses the bundle's .gnu.version_r and fails the build if any demanded GLIBC_ version exceeds 2.38. That test is the contract this issue inherits.

The proper fix is a pinned sysroot in the toolchains_llvm configuration: link everything against a fetched, sha256-pinned old-glibc sysroot instead of the host's. That closes the one non-hermetic input the build still has — today a clone builds with no system development packages installed except that it links whatever glibc the host happens to run.

What makes this a stage rather than a patch:

It touches every target, not just the bundle.
The render goldens are quantized libm output, and an older symbol set can resolve to different implementations (glibc 2.4x adopted correctly-rounded single-precision math, which is why the versions were bumped at all). The goldens must be re-verified against the sysroot's libm before this lands, and a mismatch is a re-blessing decision, not a rubber stamp — plugin/render_golden_test.cc's header carries the rules.
The hand-pinning above should be REMOVED in the same change, with glibc_floor_test kept: the test then verifies the sysroot did the job, instead of verifying the patchwork.

Done means: the symver header and the per_file_copt are gone, glibc_floor_test still passes, goldens match at fastbuild and --config=opt, and the bundle loads in Flatpak Bitwig.

The plugin GUI stage made the bundle's glibc floor visible: linking ImGui and libX11 pulled symbol versions (sqrtf/acosf @2.43, __inet_*_chk @2.42) newer than Flatpak Bitwig's runtime glibc, and the bundle stopped loading in the DAW it is developed against. The stopgap that shipped with the GUI branch pins the floor at 2.38 by hand: `.symver` bindings for the math pair, `-U_FORTIFY_SOURCE` on libx11, and `//plugin:glibc_floor_test`, which parses the bundle's `.gnu.version_r` and fails the build if any demanded `GLIBC_` version exceeds 2.38. That test is the contract this issue inherits. The proper fix is a pinned sysroot in the `toolchains_llvm` configuration: link everything against a fetched, sha256-pinned old-glibc sysroot instead of the host's. That closes the one non-hermetic input the build still has — today a clone builds with no system development packages installed *except* that it links whatever glibc the host happens to run. What makes this a stage rather than a patch: - It touches every target, not just the bundle. - The render goldens are quantized libm output, and an older symbol set can resolve to different implementations (glibc 2.4x adopted correctly-rounded single-precision math, which is why the versions were bumped at all). The goldens must be re-verified against the sysroot's libm before this lands, and a mismatch is a re-blessing decision, not a rubber stamp — `plugin/render_golden_test.cc`'s header carries the rules. - The hand-pinning above should be REMOVED in the same change, with `glibc_floor_test` kept: the test then verifies the sysroot did the job, instead of verifying the patchwork. Done means: the symver header and the per_file_copt are gone, `glibc_floor_test` still passes, goldens match at fastbuild and `--config=opt`, and the bundle loads in Flatpak Bitwig.