The build program's host toolchain under a cross target carries the host's C library (#622, 2026.9.12.4) - #627
Merged
Conversation
…ost's C library (#622)
… paths (#622) host_tc_for_build_program's cross branch called detect(frontend) with only the compiler path, unlike the native call site's three-argument form. detect() uses the second/third arguments (the host's runtime-binding identity) to probe which glibc/linux-headers xpkg payloads belong to this exact toolchain (Toolchain::payloadPaths); without them the field stays unset, so neither the explicit -isystem/-idirafter <glibc>/include rows nor the sysroot-completion symlinking that depends on it ever run. Measured in the xlings sandbox (fresh registry, real gcc@16.1.0 payload) with the released 2026.9.12.3: "Resolved host toolchain for build.mcpp: gcc 16.1.0" (the row-pin fix already gets the right compiler), then "mcpp module compile failed": features.h: No such file or directory. Fixed by passing the same runtimePayload/runtimeBindingSnapshot the native path already trusts -- the value is the host's, so it does not vary with --target. Not reliably reproducible outside a real sandbox (this dev machine's own bundled sandbox layout init fills in a usable sysroot through an unrelated path). Also adds a small observability hook (mcpp.build.hostprogram): the mcpp module's compile argv is now logged under MCPP_VERBOSE=1, which is the only way to see it on a run that succeeds.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by the sandbox verification of 2026.9.12.3 (section J, a Web project whose build program is a plugin member): under
--target wasm32-emscriptenin a fresh home, the build program's host toolchain resolved to gcc and then itsmcppmodule failed atfeatures.h. Two defects inhost_tc_for_build_program's cross branch, both fixed:detect(frontend)without the runtime payload and binding the native call passes, so the toolchain carried no C library and the module compile ran with the payload's bare search path; it now receives the host's runtime payload and binding, and the compile line carries the glibc and linux-headers include directories.The development machine masked the second defect: a subos sysroot leaked into the shared-store gcc's search path. Reproduced in a real
xlings subossandbox with the released binary and green with this branch.tests/e2e/657gains a fresh-home phase and a native build in the same home afterwards;MCPP_VERBOSE=1now prints the module compile command. Unit 113 passed; e2e 657, 630, 651, 652b, 656, 622 pass. Version 2026.9.12.4.