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).
vasilito
ecc971b4ec