BUILDING.md: dcheck_always_on, missing gclient hooks and container flags cost a full build cycle each

[d591-ai]

Three things that are not bugs in the code, but cost hours when cross-building windows on Linux from a clean clone (149.0.7827.114, container path). Related build-script issues are filed separately.

1. dcheck_always_on deserves a much louder warning

config/args.gn already explains it:

a non-official build defaults dcheck_always_on to !is_official_build = true, so upstream DCHECKs are FATAL and can crash the tab under CDP on edge inputs

In practice this is not an edge case — it is the default outcome of following BUILDING.md. A build made with the published config:

• starts and spawns its full process tree
• never opens the DevTools port
• returns empty output for --headless --dump-dom

Nothing crashes visibly, nothing is logged, and the natural conclusion is that the build is broken. It took a full second build cycle to find the answer sitting in a comment next to the flag.

Suggestion: either flip the default, or move that note into docs/BUILDING.md under a heading like "your build will start but do nothing" — the current wording reads as a future improvement rather than a blocker.

2. The tarball has no gclient, so DEPS hooks silently never run

scripts/00 unpacks the ungoogled tarball, which means everything the DEPS hooks normally fetch is simply absent. Each missing piece surfaces one at a time, hours apart, as a ninja: error: … missing and no known rule to make it:

• clang Windows runtime — update.py only fetches it when it sees target_os = ['win'], which it reads from a .gclient that does not exist. Creating one with solutions = [] / target_os = ['win'] beside src, then running tools/clang/scripts/update.py --package=clang, pulls clang-win-runtime-library-*.tar.xz
• third_party/devtools-frontend/src/third_party/esbuild (version is in devtools' package.json)
• third_party/gperf/cipd/bin/gperf (a system gperf symlink works)
• build/toolchain/win/rc/linux64/rc — the .sha1 file is stripped too, but both are recoverable: googlesource serves any file of the tag as base64 via ?format=TEXT, and GCS serves the binary by that hash
• 44 binary .tlb files under third_party/win_build_output/midl (stripped as binaries; same googlesource trick)
• Redist d3dcompiler_47.dll (xwin ships headers and import libs, not redistributables)

A single prerequisites step fetching these up front would turn six separate multi-hour round trips into one.

3. Container flags that BUILDING.md does not mention

• --device /dev/fuse --cap-add SYS_ADMIN --security-opt apparmor:unconfined — required for the ciopfs mount in stage 03, otherwise fuse: device not found
• --ulimit nofile=65536 — eight parallel compilers plus FUSE exhaust the default 1024 and fail with Too many open files. The failing target is whichever ran out of descriptors, not a broken one, so this sends you debugging the wrong component (for us: device/bluetooth)
• stages 03–05 must run in one container — the SDK include tree exists only while ciopfs is mounted, so running stage 04 separately gives Path ".../Include/10.0.26100.0/um" … does not exist while the backing store is plainly there

Bonus: CRT newer than UCRT

xwin pairs VS CRT 14.44 with UCRT from SDK 10.0.26100. threads.h from the former uses _UCRT_DISABLE_CLANG_WARNINGS and _UCRT_DISABLED_WARNINGS, which the latter's corecrt.h does not define yet:

wintoolchain/VC/Tools/MSVC/14.44.35207/include/threads.h(13,1):
error: unknown type name '_UCRT_DISABLE_CLANG_WARNINGS'

Anything pulling C11 <threads.h> fails — for us third_party/pthreadpool via XNNPACK. Defining the two macros in corecrt.h when absent is enough; they are just #pragma clang diagnostic wrappers.

[d591-ai]

Correction to item 1 — my diagnosis was wrong and I would rather retract it than leave it standing.

I attributed the "starts but does nothing" behaviour to dcheck_always_on and reported that rebuilding with it disabled was the fix. I then did that rebuild: 57126/57126 targets, zero failures, dcheck_always_on = false confirmed in the generated args.gn. The binary still does not work — it now fails differently, crashing at startup with 0xC0000409 in ntdll.dll rather than starting silently.

So dcheck_always_on may still be worth the louder warning for its own reasons, but it was not the cause of my problem, and anyone acting on item 1 as written would spend a full build cycle to reach the same dead end I did. Details of the crash are in #21.

Items 2 and 3 (missing gclient hooks, container flags) stand as written — those cost real time and are unrelated to the crash.

My working assumption now is that Linux cross-compilation is not a supported path for this project at all, given that ungoogled-chromium-windows documents its build as tested on Windows with Visual Studio. If that is right, saying so plainly in BUILDING.md would save more time than any of the individual fixes I filed.