Cooked Boost 1.81 fails to build with clang on aarch64 Linux ('cstddef' not found)

[travisdowns]

Cooked Boost 1.81 fails to build with clang on aarch64 Linux: 'cstddef' file not found

Repro

On aarch64 Linux with clang (tested with clang++-20, host glibc, GCC 11 toolchain installed):

./configure.py --cook fmt --cook GnuTLS --cook Boost \
    --compiler clang++-20 --c++-standard=20
ninja -C build/dev

Every Boost source file fails compilation with:

./boost/config/detail/select_stdlib_config.hpp:26:14: fatal error: 'cstddef' file not found
   26 | #    include <cstddef>

Sample command line emitted by B2:

/usr/bin/clang++-20 -c -x c++ ... --target=arm64-pc-linux ... libs/test/src/xml_report_formatter.cpp

Cause

tools/build/src/tools/clang.jam in Boost 1.81 (function init-flags-cross) builds an explicit --target= flag from a shared architecture/vendor map used for both darwin and linux:

• clang.jam:78 case linux : vendor = pc ; sys = linux ;
• clang.jam:88 case arm-64 : arch = arm64 ;
• clang.jam:96 : "--target=$(arch)-$(vendor-sys)"

For Apple this yields the valid arm64-apple-darwin. For Linux on aarch64 it yields arm64-pc-linux, which clang doesn't recognise as a known triple. With no recognised triple, clang locates no GCC installation and adds no C++ standard library search paths, so the first #include <cstddef> in select_stdlib_config.hpp fails.

Clang's own default triple on this host (aarch64-unknown-linux-gnu) works fine; the breakage is entirely from the --target= B2 passes.

The Seastar recipe doesn't pass architecture= or address-model= — B2 auto-detects arm + 64 and feeds it into this cross-target map.

Upstream status

Tracked in B2 as bfgroup/b2#449 "Invalid target triple selected with clang 20+" (closed Oct 2025). Symptom in that report is the same arm64-pc-linux triple emitted on aarch64 Linux. The visible breakage is recent because clang ≥20 tightened target-triple validation; older clang silently accepted the bogus triple and located headers anyway.

The closing PR bfgroup/b2#466 added an opt-in <triple> option; it did not change the default. The same broken case linux : vendor = pc / case arm-64 : arch = arm64 lines still exist on boostorg/build develop/master.

Possible remediations

• Workaround today: don't --cook Boost on aarch64 Linux with clang ≥20. Any distro Boost satisfies Seastar's minimum (currently 1.79.0 per cmake/SeastarDependencies.cmake); recent Ubuntu/Fedora/Debian all ship 1.83+.

• Future fix in the cooking recipe: bump the pinned Boost to 1.91.0 (released 2026-04-23, first release to bundle B2 ≥5.4.0 — it ships 5.4.2), and add <triple> to cook_boost.jam, e.g.:

  using clang : … : <triple>aarch64-unknown-linux-gnu ;
  # or, to suppress the auto-deduced flag entirely and pass it manually:
  using clang : … : <triple>none <cxxflags>--target=aarch64-unknown-linux-gnu <linkflags>--target=aarch64-unknown-linux-gnu ;
  

  A bump alone is not sufficient — 1.91.0 still emits the bogus default triple unless <triple> is set.

Environment

• Host: Ubuntu, Linux aarch64 (kernel 6.8)
• Compiler: clang++-20
• Boost: 1.81.0 (the version pinned in cooking_recipe.cmake)
• Seastar: master (commit 510f3148)