install hooks cannot see the consumer's standard library, so a source-built static package can never match its ABI

[Sunrisepeak]

Summary

An xlings install hook that builds a package from source has no way to learn which C++ standard library the consumer will link against. For a package that ships static libraries, that makes a correct build impossible: std::__cxx11:: symbols cross the boundary, and a libc++ consumer fails at link.

Measured

mcpp-index's compat.mysql-connector-cpp builds MySQL Connector/C++ from source with CMake and the system compiler. On the index's linux llvm leg (clang + libc++):

ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::_M_create(unsigned long&, unsigned long)
ld.lld: error: undefined symbol: std::__throw_logic_error(char const*)
ld.lld: error: undefined symbol: vtable for std::__cxx11::basic_stringstream<...>
mysql-connector-cpp   386s   FAIL

A probe was added to the install hook to log MCPP_CXX_STDLIB whatever its value (mcpplibs/mcpp-index#392). It reports:

11:46:18 MCPP_CXX_STDLIB=nil

Why, in this source tree

1. The only setter is the build-program path. src/build/build_program.cppm:

   e.emplace_back("MCPP_CXX_STDLIB", env.cxxStdlib);

   mcpp::cxx_stdlib() (src/build/hostprogram.cppm) reads it back. Both belong to a build program; an xlings install hook is not one.

2. The install call carries no toolchain. make_xlings_env returns an xlings::Env of {binary, home, projectDir}, and install_packages is invoked with XLINGS_HOME and PATH:

   cd <home> && env -u XLINGS_PROJECT_DIR XLINGS_HOME=<home> xlings interface install_packages --args …
   

   Nothing about the compiler, the toolchain, or the standard library crosses that boundary.

Why the existing workarounds do not reach

• llamacpp refuses a libc++ toolchain by name with mcpp::cxx_stdlib() — but that lives in its build program, in its own repo. An inline descriptor has no such place.
• [target.'cfg(...)'] self-gating has a platform axis and no standard-library axis. As src/pm/publisher.cppm puts it, a cfg selector is not a platform.

So a package in this position can neither adapt nor refuse. Today the index keeps the member off the llvm leg in CI, which is honest but is CI policy standing in for a missing capability.

What would close it

Any one of these; listed smallest first, no strong preference:

1. Export MCPP_CXX_STDLIB (and plausibly the compiler id) into the environment of install_packages, so an install hook can read what a build program reads.
2. Pass the selected toolchain through xlings::Env so xlings can hand it to hooks as first-class data rather than an environment variable.
3. Give descriptors a way to declare an ABI requirement that mcpp checks before building, so the failure is a clear diagnostic at resolve time instead of a link error later.

(1) alone would let the descriptor in mcpplibs/mcpp-index#392 become a three-line change and let the CI entry come out.

Not urgent

The affected package is usable on every other leg, and the index documents the limitation where a user reads it. Filing so it is recorded rather than rediscovered.

[Sunrisepeak]

Addressed in mcpp 2026.9.12.2 (#619). One part of the request cannot be provided, and the reason is measured.

What the hook receives. A dependency's install hook now receives MCPP_TARGET and its segments under the names build programs use. It also receives MCPP_COMPILER and MCPP_CXX_STDLIB, present and empty, so a hook never reads a value inherited from its parent.

Why the toolchain values are empty. They cannot be filled: mcpp resolves the toolchain after the dependency graph is installed, because a package in the graph may supply a target-side layer, so no standard library has been decided when a dependency installs. tests/e2e/648 measures this, and the design record's §11 states it.

What refuses the mismatch. The existing layer requirement. A package compiled against one C++ standard library states it in its descriptor, and a consumer on the other implementation is refused at resolution, naming both:

linux  = { requires = { "mcpp:c++-abi=libstdc++" } },
macosx = { requires = { "mcpp:c++-abi=libc++" } },

compat.mysql-connector-cpp declares exactly this (mcpplibs/mcpp-index#399). The requirement is per platform because its install hook uses each platform's system compiler, and the macOS CI leg refused an unconditional libstdc++ requirement. docs/06, docs/22 and docs/32 state the recipe.

A store keyed by variant, which would let one version exist in two flavours, remains an xlings matter and is out of scope.