Source: chromium Version: 155.0.8059.39-1 Severity: important Tags: ftbfs patch
chromium has not built on armhf since 150.0.7871.181-1 on July. The nine builds attempted since have all failed, each after 17 to 19 hours of buildd time, always at the final link of chrome: ld.lld-22: error: failed to open ./chrome: Cannot allocate memory https://buildd.debian.org/status/logs.php?pkg=chromium&arch=armhf Cause ----- The final link does not fit in a 32-bit address space. Measured by bisecting RLIMIT_AS on a replayed link of v8_context_snapshot_generator, a target that carries about half of chrome's input: needs 3.25 GB available to an AArch32 process on an arm64 kernel about 4 GiB Peak RSS for the same link is 2.30 GB. Watching RSS is misleading here: address space runs about 40% higher, and it is the address space that the allocation fails on. What I have tried and did not work: ld.bfd 2.47 --no-keep-memory --reduce-memory-overheads 6.04 GB RSS ld.bfd 2.47 plain 6.69 GB RSS ld.gold 2.44 11.32 GB RSS, then an internal error mold maps every input and the output optimize_for_size=true object files grow 19% --icf=all shrinks only the output, the small term -fno-function-sections saves 97 bytes per input section, costs more staged partial linking higher than the direct link mold's author reached the same conclusion for a program this size in https://github.com/rui314/mold/issues/1701 : cross building on a 64-bit host is the only option. We tried this approach previously: Cross hosting the linker, an arm64 lld or mold against armhf objects. it does work: https://salsa.debian.org/chromium-team/chromium/-/merge_requests/44 https://salsa.debian.org/chromium-team/chromium/-/merge_requests/45 Both need a build dependency from a foreign architecture, which wanna-build infrastructure from the buildd team does not suppor. That is https://bugs.debian.org/770925 , open since 2014. A patch for it with tests is at https://salsa.debian.org/mendezr/wanna-build/-/merge_requests/1 and it was declined at the beginning of Octuber 2026. Hence, a proposal to fix it: --- Building chrome as a component build on armhf. The code then lives in about 540 shared libraries that link one at a time, chrome's own link inputs drop from over 2 GB to 569 MB, and the largest remaining link is 434 MB. https://salsa.debian.org/chromium-team/chromium/-/merge_requests/49 The packages install and the browser runs, although so far I have tested it only under qemu-user. If anyone has armhf hardware, a native check would be welcome. The merge request needs two patches that are also upstream: https://chromium-review.googlesource.com/c/chromium/src/+/8545999 https://chromium-review.googlesource.com/c/chromium/src/+/8549218 The reasoning and the measurements are in debian/README.armhf in that branch, so this does not have to be worked out again. Again, the MR for this approach is in: https://salsa.debian.org/chromium-team/chromium/-/merge_requests/49
