[bong-water-water-bong]

The Lemonade half of #1461. lemond ships 126 build-machine paths and lemonade 13 (measured on the c32 image, read out of the stick's SFS), every one of them the roll's own work directory:

/home/bcloud/wt/release-rc/work/src/third_party/lemonade/src/cpp/server/server.cpp

So two rolls of the same commit produce different payload bytes, and a sha handed to a user cannot be reproduced from the source alone. The Lemonade build sets no prefix map at all (scripts/build-lemonade.sh ran plain cmake -S … -B …).

What this does: maps both roots to stable relative ones — the source tree to lemonade, the build directory to build — for __FILE__ and for the debug info (-fdebug-prefix-map; Release here keeps -g, and the same string lives there). Both roots because the leaked paths come from real sources now and could come from a generated file later.

What it does not do: the Loom half of #1461 (7 strings in libloomc.so.0) is not fixable from this repo. third_party/llama.cpp's ggml/src/ggml-hrx/CMakeLists.txt builds the nested deps with an explicit GGML_HRX_CMAKE_ARGS list — CMAKE_BUILD_TYPE, compilers, the IREE driver switches — that never forwards CMAKE_C_FLAGS/CMAKE_CXX_FLAGS, so the engine's -ffile-prefix-map (cmake/hrx.cmake) stops at the llama.cpp boundary and Loom's __FILE__ stays absolute even though the engine maps its own objects correctly. That needs a change on the llama.cpp fork (forward the flags) plus -ffile-prefix-map=${CMAKE_BINARY_DIR}=build on the engine side, because the Loom sources are fetched into the build tree.

Ordering, so nobody trips it: the maps first, then hoisting the payload gate row from 1bit to every ELF. Hoisting first fails every roll until both maps land.

Verification state, stated honestly: static check done — Lemonade has no CMAKE_CXX_FLAGS assignment anywhere, so the -D values are not overwritten, which was the one way this PR could have been silently empty. The build-and-count verification (strings -a lemond | grep -o -E '/home/|/wt/' | wc -l, expected 0 against today's 126) is queued behind the running c33 payload roll: two CPU builds at once would double-book the thermal governor, which exists so a hot die does not starve the GPU queue. I will report the number from the rebuilt binary before this is proposed for merging, not after.

The build now also prints that count itself, counting occurrences rather than lines — one of lemonade's 13 did not start its line (a strings run glues it to its neighbours), so an anchored grep reports 145 of 146.

Refs #1461

[bong-water-water-bong]

VERDICT: READY at d5a7afd7f00fbb11e94883d7bbc86427b5a652e7.

The measured problem (139 build-machine paths in the payload — lemond 126, lemonade 13, read out of the c32 image) has exactly one cause and this maps exactly that cause:

-ffile-prefix-map=$src=lemonade       -fdebug-prefix-map=$src=lemonade
-ffile-prefix-map=$prefix/build=build -fdebug-prefix-map=$prefix/build=build

Both roots (source tree and build dir), and both -ffile- and -fdebug- maps — the second pair matters because -g is on in this Release build and the same string lives in debug info, which is the half a __FILE__-only fix would have left behind. scripts/build-lemonade.sh previously set no prefix map at all, which is why two rolls of the same commit produced different bytes; that is now the only thing this PR changes about the build.

The reproducibility rationale is stated where a reader needs it: a sha handed to a user must be reproducible from the source alone. Worth pairing (later) with #1465's gate, which is the engine half of the same rule — the two together are "no payload names its builder".

[bong-water-water-bong]

Mechanism verified directly, so the remaining verification is only "does Lemonade's build pass these flags through" - not "does the map work":

$printf 'const char* f(void){ return __FILE__; }' > …/lemonade/third_party/lemonade/src/cpp/server/server.cpp
g++ -O2 -ffile-prefix-map=/tmp/pathtest/lemonade=lemonade -fdebug-prefix-map=/tmp/pathtest/lemonade=lemonade -c …/server.cpp

  with the map:  lemonade/third_party/lemonade/src/cpp/server/server.cpp
  without it:    /tmp/pathtest/lemonade/third_party/lemonade/src/cpp/server/server.cpp

Both halves matter for this PR's shape: the string is rewritten from the source root (which is what leaks today: …/wt/release-rc/work/src/third_party/lemonade/src/cpp/server/server.cpp), and the rewrite lands on a relative path, which is what makes two rolls of one commit produce the same bytes.

And the call path is confirmed, which was the other way this could have been silently empty: scripts/weekly.sh invokes this script twice - line 206 (guard "$SRC/scripts/build-lemonade.sh" "$W/lemonade", the build stage) and line 555 (LEMONADE_WEB_APP=1 guard …, the package stage) - so both shipped binaries (bin/lemond, bin/lemonade) are built by the file this PR changes, not by some private cmake elsewhere.

Still owed: the count off the rebuilt lemond (expected 0 against today's 126), which needs a build slot rather than a reading; I am not double-booking the thermal governor while the c33 image cut is compressing.

[bong-water-water-bong]

Post-merge verification, the number I said I would report "before this is proposed for merging, not after" — the PR merged first, so here it is after, with the same standard.

Built lemond from the merged script against the c33 payload's Lemonade submodule, under thermal-run:

CMAKE_CXX_FLAGS: -ffile-prefix-map=/home/bcloud/wt/os3-c33/third_party/lemonade=lemonade
                 -fdebug-prefix-map=…=lemonade -ffile-prefix-map=…/build=build -fdebug-prefix-map=…/build=build
CMAKE_C_FLAGS:   (the same four)

That first line is the evidence I cared most about, because it is the way this PR could have been silently empty: cmake does not echo the flags, so "did the map arrive" is only answerable from the cache, not from the log. It arrived.

$ strings -a …/bin/lemond | grep -o '/home/' | wc -l
0                      # c32 and c33 shipped 126

and the rebuilt lemond is 18,278,448 B against the shipped 18,290,736 B - 12,288 B smaller, which is what 126 shortened paths look like.

So the Lemonade half of #1461 is fixed and measured: 126 → 0. The Loom half (7 strings in libloomc.so.0) is not fixed and cannot be from this repo - third_party/llama.cpp's ggml/src/ggml-hrx/CMakeLists.txt builds the nested deps with an explicit GGML_HRX_CMAKE_ARGS list that never forwards CMAKE_C_FLAGS/CMAKE_CXX_FLAGS, so the engine's map stops at the llama.cpp boundary. That needs the fork change plus -ffile-prefix-map=${CMAKE_BINARY_DIR}=build on the engine side, as #1461 describes. Until then the payload is not byte-reproducible, and the qualification in docs/releases.md stays.

One note on how this was produced, since the number now has a life of its own: I invoked the script with two arguments when its usage is one (<prefix>), so $2 was silently ignored and the build landed in the payload roll tree rather than where I meant. The count is unaffected - same sources, same flags, verified from the cache - but the paths in this comment are where the build actually happened, not where I intended it to.

[bong-water-water-bong]

Evidence kept this time, and a better fact than the zero: the strings are relative, not absent.

/home/bcloud/wt/lem-verify/bin/lemond   18,278,448 B   sha256 75076a635f2d1880...
  /home/ occurrences: 0    /wt/ occurrences: 0
  names instead:  lemonade/src/cpp/server/server.cpp
                  lemonade/src/cpp/server/core/api_route.cpp
/home/bcloud/wt/lem-verify/EVIDENCE.txt           source commit, command, size, sha, count, cache flags
/home/bcloud/wt/lem-verify/build/CMakeCache.txt   CMAKE_CXX_FLAGS with all four maps

Zero alone could also be a build that lost its debug info. lemonade/src/cpp/server/server.cpp can only come from -ffile-prefix-map rewriting it - that is the difference between "I counted no /home/" and "the paths are there and they are relative", and it is the sentence I should have written the first time.

Also: my first report of this number deleted the build directory in the same breath, so it was unreproducible - pi-release searched and found nothing, correctly. A claim whose evidence is gone is folklore, even when the claim is true; the directory now stays put.