max / alloy

docs: the glibc conclusion was right, my reasoning for overturning it was not Corrects the block added in 5edae13 earlier today. That commit measured the executable's glibc floor, found it identical on both hosts, and concluded that building the apps natively on Alloy would not raise the floor. The measurement stands. The conclusion does not, and 0.2's original verdict survives. The AppImage's floor is not the executable's floor. cargo-tauri copies the WebKit libraries into the bundle and linuxdeploy excludes libc from what it bundles, so those copies have to load against the user's glibc. Measured by installing webkit2gtk4.1 2.52.5-1.fc43 into a throwaway container off the client image: libwebkit2gtk-4.1 requires GLIBC_2.42, Fedora 43's own. libjavascriptcoregtk-4.1 wants 2.38 and is not the constraint. Ubuntu 24.04 LTS is 2.39, so a natively built release would not start for anyone on the current LTS. So the Tauri build belongs in a Debian-family distrobox, which is where 0.2 already pointed, and the reason is now a correctness requirement rather than the weight preference it was argued as. 5edae13 flagged the bundled libraries as untested and then drew a conclusion that needed them tested. Both halves are kept in the file: the executable measurement is true and worth having, and it is no longer carrying a verdict it cannot support. Both limits stated: the Rust half covers std and not C dependencies built against Fedora headers, and the WebKit half measures the shipped library rather than a bundle from a real cargo tauri build on Alloy, which has not been run. No code changed. Nothing pushed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Max Johnson <me@maxj.phd> · 2026-08-21 18:49 UTC

Signed with PGP, not checked

Commit: f8acd7819b48f15eb16b0890e4b16dc68abb25d9

Parent: 7f82670

1 file changed, +6 insertions, -2 deletions

M docs/MIGRATION-FW13.md +6 -2

			@@ -80,9 +80,13 @@
80	80
81	81		That last point was a reading, and the measurement does not support it. Measured 2026-08-21 by compiling the same source on both hosts and reading `objdump -T`. The Alloy image is glibc 2.42 (`glibc-2.42-13.fc43`) against fw13's 2.39, so the premise about the hosts is right. The conclusion is not. A Rust binary exercising fs, threads, time, net and collections floors at GLIBC_2.34 built either place, identically. Add process spawning, which is what pulls the newest symbols the tree actually uses, and both hosts produce GLIBC_2.39 from the same two symbols, `pidfd_getpid` and `pidfd_spawnp`. The deployed `makenotwork` binary built on fw13 today already requires GLIBC_2.39 for exactly those two, plus `hypotf` at 2.35.
82	82
83		-	So the floor is set by which symbols the code uses and by what rustc's own feature detection reaches for, not by the build host's glibc version, and on this code both hosts reach the same place. Building the apps natively on Alloy would not raise the floor above where fw13 already puts it.
	83	+	So for the executable the floor is set by which symbols the code uses and by what rustc's feature detection reaches for, not by the build host's glibc version, and on this code both hosts reach the same place. The reasoning in the original claim is wrong. The conclusion it reached is right anyway, for a different reason, and that reason is the stronger one.
84	84
85		-	Two limits on that, stated so nobody over-reads it. It measures Rust std only: a C dependency compiled by `cc` against Fedora 43 headers could still pick up a newer symbol, and none of `openssl-sys`, `libsqlite3-sys` or the webkit glue was tested. And it says nothing about the libraries linuxdeploy bundles into the AppImage, which is a separate question from the executable's own floor. What it does settle is that the strongest stated argument for keeping the Tauri build in a Debian-family box does not hold in the form it was written.
	85	+	The AppImage's floor is not the executable's floor. cargo-tauri copies the WebKit libraries into the bundle and linuxdeploy deliberately excludes libc from what it bundles, so those copied libraries meet whatever glibc the user has. Measured 2026-08-21 by installing `webkit2gtk4.1` (2.52.5-1.fc43) into a throwaway container off the client image and reading `objdump -T`: `libwebkit2gtk-4.1` requires GLIBC_2.42, which is Fedora 43's own. `libjavascriptcoregtk-4.1` requires 2.38 and is not the constraint. fw13's current WebKit is 2.52.3 from Ubuntu 24.04 and carries no such requirement.
	86	+
	87	+	That is decisive, and it decides the item. An AppImage built natively on Alloy would carry a WebKit that will not load on Ubuntu 24.04 LTS, which is glibc 2.39 and is the current LTS. Not a weight preference and not a matter of taste: the release would fail to start for the people most likely to download it. The Tauri build belongs in a Debian-family distrobox, and the argument is the bundled libraries rather than the compiled executable.
	88	+
	89	+	Two limits, stated so nobody over-reads the Rust half. It measures Rust std only, so a C dependency compiled by `cc` against Fedora 43 headers could still pick up a newer symbol, and none of `openssl-sys` or `libsqlite3-sys` was tested. And the WebKit measurement is of the library Fedora ships, not of a bundle produced by an actual `cargo tauri build` on Alloy, which has not been run.
86	90
87	91		### 0.3 The six that degrade rather than block
88	92