LLVM_DEFAULT_TARGET_TRIPLE was ${TARGET} (redox), so the host clang defaulted
to x86_64-unknown-redox and searched the Redox sysroot for the C++ stdlib when
libclc compiled its host prepare_builtins.cpp -> 'type_traits' file not found.
A host clang must default to the host triple (the redoxer toolchain's clang
does exactly this: Target x86_64-unknown-linux-gnu). Set it to
${COOKBOOK_HOST_TARGET}. libclc's .cl->bitcode compiles pass -target amdgcn
explicitly, so the host default does not affect them.
llvm-native's job is to supply a COMPLETE host LLVM dev tree (host clang +
host static component libs + matching cmake/llvm export) that libclc's
find_package(LLVM) and host clang need for Mesa's iris/radeonsi CLC path. The
redoxer toolchain ships host clang + libLLVM.so but strips the static libs, so
find_package fails — and stubbing them violates the no-stub policy.
The recipe was WRONGLY cross-compiling LLVM for the Redox target via
cookbook_cmake: that (a) produces host-unusable Redox binaries and (b) fails to
link because Redox's libstdc++ lacks symbols LLVM uses (std::random_device
etc.). My earlier LLVM_USE_HOST_TOOLS=OFF / tblgen-var / native.cmake patches
were all treating symptoms of that wrong architecture.
Rewrite: build entirely with the host gcc, targeting the host, exactly like
libclc builds its own host prepare_builtins tool — invoke cmake directly (not
cookbook_cmake) with /usr/bin/gcc and no CMAKE_SYSTEM_NAME so CROSSCOMPILING is
false (LLVM builds one native tblgen with host gcc; no NATIVE sub-project, no
Redox-header leak). Drop all Redox build-deps and the llvm21.runtime package
dep. Validated: host GCC 16.1.1 configures LLVM 21 and builds llvm-min-tblgen +
libLLVMSupport.a/libLLVMTableGen.a cleanly.
This is how upstream-style host LLVM tooling should be produced; it supersedes
the cross-build patch chain (312659fe21, 5d426d89a7, 872935057c, b2d9a31a4f).
Even with LLVM_TABLEGEN/CLANG_TABLEGEN provided, LLVM_USE_HOST_TOOLS defaults
ON when cross-compiling, so llvm/CMakeLists.txt creates the NATIVE external
project (llvm_create_cross_target LLVM NATIVE) — a full second HOST LLVM build
that inherits the Redox cross flags and died compiling native llvm-config.
We already supply the only native tools a cross-build needs (the tablegens),
so OFF eliminates the native sub-build entirely; LLVM uses the provided host
tblgens for .inc generation. Completes the llvm-native cross-build fix chain
(native-link, OPTIMIZED_TABLEGEN, LLVM_TABLEGEN var name, and now this).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Root cause of the native sub-build failure. A from-scratch LLVM build reads
the cache vars LLVM_TABLEGEN / CLANG_TABLEGEN to skip building a native
tblgen when cross-compiling (llvm/cmake/modules/TableGen.cmake: "Native
TableGen executable. Saves building one when cross-compiling"). The recipe
passed *_TABLEGEN_EXE, which that path does NOT read, so LLVM built its own
native tblgen via the CROSS_TOOLCHAIN_FLAGS_NATIVE sub-build. That native
build ran host gcc against Redox relibc headers (leaked via CMAKE_CXX_FLAGS)
and died on host/redox <stdlib.h> conflicts: __deprecated/__noreturn not a
type, duplicate div_t/ldiv_t. Passing the correct var names makes LLVM use the
redoxer toolchain's host tblgens (LLVM 21.1.2) and skip the native build.
lld21/clang21 build against a PREBUILT llvm and resolve tblgen via
find_program on their own LLVM_TABLEGEN_EXE cache var, so they stay correct.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two fixes for the native tblgen sub-build failing on <shared_mutex>:
- LLVM_OPTIMIZED_TABLEGEN=Off: this recipe already provides a host-runnable,
version-matched llvm-/clang-tblgen (redoxer toolchain, LLVM 21.1.2) via
*_TABLEGEN_EXE. OPTIMIZED_TABLEGEN=On ignored those and forced a redundant
native sub-build (CROSS_TOOLCHAIN_FLAGS_NATIVE) that failed. Off => LLVM uses
the provided tblgen and skips the native build. (llvm21 provides no tblgen,
so it keeps On and builds its own — different case, left as-is.)
- CMAKE_CXX_FLAGS --std=gnu++11 -> gnu++17: LLVM 21 requires C++17; the stale
gnu++11 could win the flag-order race in any sub-build and break the headers.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The native tablegen/tools sub-build (CROSS_TOOLCHAIN_FLAGS_NATIVE) generated
native.cmake against $COOKBOOK_TOOLCHAIN (the Redox cross sysroot) and never
cleared the inherited cross CMAKE_*_FLAGS, so the host try_compile linked
relibc and died with 'undefined reference to __libc_start_main'. Port llvm21's
proven fix: save+unset LDFLAGS/CFLAGS/CXXFLAGS, generate native.cmake against
/usr, CACHE FORCE-clear the cross flags for the native sub-cache, and restore
the cross flags via -DCMAKE_*_FLAGS (not the environment) for the cross build.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Cross-building lld/llvm needs a HOST-runnable llvm-tblgen to generate the
Options.inc opt-parser sources, and it must match the LLVM 21 source tree.
Both recipes referenced ${COOKBOOK_HOST_SYSROOT}/bin/llvm-tblgen, but the
cookbook does not export COOKBOOK_HOST_SYSROOT, so the path collapsed to the
host /bin/llvm-tblgen. On a rolling distro that is now LLVM 22, whose
-gen-opt-parser-defs backend requires a 'SubCommand' TableGen class absent
from LLVM 21's OptParser.td:
error: The class 'SubCommand' is not defined
Default COOKBOOK_HOST_SYSROOT to the redoxer toolchain (host-runnable LLVM
21.1.2 llvm-/clang-tblgen), exactly as the sibling clang21 recipe already
does. Fixes the full-target build reaching mesa's LLVM build-deps.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
vasilito