marfrit/marfrit-packages
0
0
Fork 1
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
7bb2fbeca9f553fe70f1bacb5764772e97e65689
marfrit-packages/arch/chromium-fourier/NEXT.md
T
test0r 7bb2fbeca9
build and publish packages / distcc-avahi-aarch64 (push) Successful in 35s
Details
build and publish packages / lmcp-any (push) Successful in 7s
Details
build and publish packages / lmcp-debian (push) Successful in 5s
Details
build and publish packages / claude-his-any (push) Successful in 7s
Details
build and publish packages / ffmpeg-v4l2-request-aarch64 (push) Successful in 12m18s
Details
build and publish packages / claude-his-debian (push) Successful in 5s
Details
chromium-fourier: pivot to x86_64 cross-compile from CT220 on data 
Earlier framing was wrong — the wall isn't 'Arch ARM clang 22 vs Arch
x86_64 clang 23'. Arch x86_64 is also on 22.1.3; LLVM 23 isn't anywhere
in extra/staging. The flags chromium 147 emits come from chromium's
clang fork (Google maintains an LLVM fork with chromium-specific
passes), not upstream LLVM 23. PKGBUILD'ing clang 23 is the wrong tree.

Right tree: cross-compile from x86_64 so chromium's bundled clang
prebuilt is reachable. CIPD has full linux-amd64 prebuilts, gclient
sync works cleanly, no qemu-x86_64-static dance needed.

his provisioned CT 220 chromium-builder-x86 on data (Ryzen 7 1700,
14 cores, 32 GiB RAM, 200 GiB ZFS). data is normally asleep — woke
via /opt/herding/bin/wake-data. Reach pattern: hertz -> ssh data ->
pct exec 220.

Source fetch running as chromium-fetch.service transient unit on
CT 220. Once src is in, plan: tools/clang/scripts/update.py for
chromium's bundled clang + arm64 sysroot, gn gen with target_cpu=arm64,
build, transfer aarch64 binary to ohm/fresnel/ampere.

boltzmann chromium-builder LXD container preserved as fallback; can
be torn down if cross-compile pans out.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 05:57:14 +00:00

7.2 KiB
Raw Blame History

chromium-fourier — first-build status (2026-04-26 00:42 UTC)

Where we are

Build environment: chromium-builder LXD container on boltzmann (8 cores, 28 GB RAM cap, 824 GB NVMe, Beryllium OS rkr3 host kernel). Source: chromium-147.0.7727.116 release tarball extracted at /build/chromium/src (25 GB extracted).

gn gen out/Default succeeds with our 7Ji-style args (use_v4l2_codec=true use_v4lplugin=true use_linux_v4l2_only=true use_vaapi=false, system toolchain via unbundle:default, system clang at /usr/bin/clang, version-symlink /usr/lib/clang/23 → /usr/lib/clang/22, compiler-rt-adjust-paths style suffix patch manually applied). 28057 targets generated.

ninja -C out/Default chrome fails immediately with two distinct walls:

Wall 1 — clang version mismatch (chromium 147 ↔ Arch clang 22)

Chromium 147's compile flags include -fno-lifetime-dse and -fsanitize-ignore-for-ubsan-feature=array-bounds. Both are clang 23+ features. Arch Linux ARM ships clang 22.1.3 (extra repo). Every single C++ compile fails with clang++: error: unknown argument.

Resolutions, in order of effort:

  • (a) Wait for Arch ARM to bump clang to 23. Tracking package upstream — happens whenever LLVM 23 lands in extra. Days to weeks.
  • (b) Use chromium's bundled clang via tools/clang/scripts/update.py. That hits the same CIPD/gs:// "linux-arm64 isn't a first-class target" issue we saw with gclient sync earlier — chromium's clang prebuilts are x86_64-only for many platforms.
  • (c) Fork an older chromium (e.g., 132 or 138) that compiles cleanly with clang 22. 7Ji's chromium-mpp PKGBUILD targets 132 and builds clean on Arch ARM today. Loses 15 versions of upstream chromium evolution but ships fast.
  • (d) Patch chromium 147 to drop the offending flags (build/config/compiler/BUILD.gn has the cflags lists). 50–200 line patch, brittle across version bumps but tractable. Fights every rebase.

Wall 2 — bundled x86_64 esbuild under qemu

After Wall 1 (or independently for Action targets): qemu-x86_64-static: Could not open '/lib64/ld-linux-x86-64.so.2' when chromium runs the bundled x86_64 esbuild from third_party/devtools-frontend/.../scripts/build/typescript/ts_library.py. Same shape as the bundled node-linux-x64 issue we already fixed (we symlinked system node into that path). esbuild needs the same treatment — install system esbuild via npm install -g esbuild and symlink it into the path chromium expects. Or install qemu-user-static

  • glibc-x86_64 to make the bundled binary actually run.

Wall 2 is much smaller than Wall 1 — a handful of bundled-x86_64 binaries to identify and replace, vs. fundamental clang version mismatch.

What worked

  • LXD container provisioning on boltzmann via his recommendation — the host environment is right.
  • Tarball-instead-of-gclient approach — sidesteps CIPD-doesn't-have- linux-arm64 problem for source acquisition, leaves only a few bundled binary issues at build time.
  • Wall 1 / Wall 2 are both identifiable and bounded. We're past the "is this even doable" phase; this is now down to grinding the patches.

Options — needs your call

  1. Grind through Wall 1 with patches — patch build/config/compiler/BUILD.gn to drop flags clang 22 doesn't know. Iterate per build error. Estimated 5–15 patch-and-retry cycles to compile clean. Then 6–10 h actual build.
  2. Pin to chromium 132 — match 7Ji's known-working version on Arch ARM. Drop our STUDY focus on "current upstream Chromium" and ship a 1-year-old binary. Build should work much sooner.
  3. Pin to chromium 138 or 140 — middle ground. Likely uses clang 22 features and not 23. Some research needed to find the cutover.
  4. Use chromium's bundled clang — not viable on linux-arm64 without extensive sysroot setup; same CIPD issue as gclient sync.
  5. Wait for Arch ARM clang 23 — passive, days-to-weeks horizon.

Recommended (FWIW): start with (3) — find the latest chromium version that builds clean against clang 22 (probably 138-141 range), ship that as chromium-fourier, then bump as Arch ARM bumps clang. That gives us a working browser in a few hours rather than days, on mainline Linux + Wayland + V4L2 unlock — which is the actual goal. The "current upstream Chromium" requirement was nice-to-have, not essential.

State of the build host (preserved)

  • Container: chromium-builder on boltzmann (running, idle)
  • Source: /build/chromium/src (extracted tarball, 25 GB)
  • Build dir: /build/chromium/src/out/Default (gn-gen'd, no artifacts)
  • Tools installed: gn, ninja, clang 22, lld, gperf, nodejs (system), rust, qt5/6, all the gtk/wayland/va/v4l deps from the long pacman shopping list
  • Patches applied to source: compiler-rt-adjust-paths style (manual)
  • Symlinks: /usr/lib/clang/23 → /usr/lib/clang/22, third_party/node/linux/node-linux-x64/bin/node → /usr/bin/node
  • Service unit history: chromium-fetch.service (one-shot, succeeded on tarball + extract); chromium-build.service (one-shot, three failed attempts above).

Discard the container and start over with option 2 if you pick that direction; otherwise iterate from current state.

Pivot 2026-04-26 — cross-compile from x86_64

After the analysis above, the framing shifted. The real wall isn't "Arch ARM clang 22 vs LLVM 23" — Arch x86_64 is also on llvm 22.1.3, no LLVM 23 anywhere in extra/staging. The flags chromium 147 emits (-fno-lifetime-dse, -fsanitize-ignore-for-ubsan-feature=array-bounds, the /usr/lib/clang/23/... path) come from chromium's clang fork, not upstream LLVM 23. Chromium ships its own LLVM with chromium-specific passes; the "23" in the path is chromium-internal versioning.

Implication: PKGBUILD'ing clang 23 is the wrong tree. The right tree is either pin to an older chromium (option 2 above) or cross-compile from an x86_64 host so chromium's x86_64 bundled clang prebuilt is reachable and target_cpu="arm64" produces the aarch64 binary cleanly. Cross-compile sidesteps every wall we hit:

  • CIPD has full linux-amd64 prebuilts (the gap was linux-arm64)
  • Chromium's bundled clang downloads cleanly on x86_64
  • No qemu-x86_64-static dance for tools (host IS x86_64)
  • tools/clang/scripts/update.py works as Google intends
  • gclient sync works; no DEPS surgery needed

his provisioned a cross-build host for this on 2026-04-26:

  • CT 220 chromium-builder-x86 on data, x86_64 Ryzen 7 1700, 14 cores, 32 GiB RAM + 8 GiB swap, 200 GiB ZFS rootfs.
  • Reach via mcp__hub-tools__remote_shell host=hertz → ssh root@192.168.88.30 (data) → pct exec 220 -- ...
  • builder user uid 1001, NOPASSWD sudo, DisableSandbox in pacman.conf.

Source fetch started 2026-04-26 05:45 UTC as transient unit chromium-fetch.service on CT 220. Estimated 1-2 h for fetch --no-history chromium over the LAN. Then tools/clang/scripts/update.py to install chromium's bundled clang (x86_64 host, arm64 sysroot), then gn gen with target_cpu="arm64" + cross-compile flags, then build.

The boltzmann chromium-builder LXD container is preserved as fallback but no longer the active build host. If cross-compile pans out, that container can be torn down.

Reference in New Issue View Git Blame Copy Permalink