diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml index 04d98127..9429419f 100644 --- a/.github/workflows/validate.yml +++ b/.github/workflows/validate.yml @@ -1206,13 +1206,18 @@ jobs: # ld.lld: error: undefined symbol: # std::__cxx11::basic_string<...>::_M_create(...) # - # Its install hook cannot adapt, because nothing tells it what the - # consumer chose: MCPP_CXX_STDLIB is exported only when mcpp runs a - # BUILD PROGRAM (`src/build/build_program.cppm`), `make_xlings_env` - # carries `{binary, home, projectDir}` and no toolchain, and a probe - # in the hook measured `MCPP_CXX_STDLIB=nil` on this very leg (#392). - # mcpp-community/mcpp#613; when the hook can see the consumer's stdlib, - # this entry comes out and the descriptor does the work instead. + # Its install hook cannot adapt: mcpp resolves the toolchain after the + # dependency graph, so the consumer's standard library does not exist + # yet when the hook runs, and MCPP_CXX_STDLIB is nil (older mcpp) or + # empty (2026.9.12.2 and later) there (#392; mcpp-community/mcpp#613, + # measured by its tests/e2e/648). The descriptor states the + # requirement instead, `requires = { "mcpp:c++-abi=libstdc++" }` in its + # `linux` table, and a libc++ consumer is refused at resolution naming + # both implementations. (On macOS the libraries are built with Apple + # clang, and the `macosx` table requires libc++, which the default + # toolchain there resolves.) + # That refusal follows the hook's source build, so the member stays off + # this leg: the leg would spend the build to reach a known refusal. # # SKIPPED, NOT MARKED GREEN: the incompatibility is real for users on # a libc++ toolchain. This stops CI from re-measuring a known answer diff --git a/pkgs/c/compat.mysql-connector-cpp.lua b/pkgs/c/compat.mysql-connector-cpp.lua index 90b598f5..c9d27843 100644 --- a/pkgs/c/compat.mysql-connector-cpp.lua +++ b/pkgs/c/compat.mysql-connector-cpp.lua @@ -51,13 +51,22 @@ package = { ["compat.openssl"] = "3.5.1", }, + -- THE STANDARD LIBRARY THE STATIC LIBRARIES WERE COMPILED AGAINST, per + -- platform, because install() uses each platform's system compiler: + -- g++ with libstdc++ on Linux, Apple clang with libc++ on macOS. A + -- consumer whose toolchain resolves the other one is refused at + -- resolution, naming both, instead of failing at link. An mcpp older + -- than the layer grammar reports the key as unknown and proceeds as + -- before. linux = { + requires = { "mcpp:c++-abi=libstdc++" }, ldflags = { "-Llib", "-l:libmysqlcppconnx-static.a", "-l:libmysqlcppconn-static.a", "-lresolv", }, }, macosx = { + requires = { "mcpp:c++-abi=libc++" }, ldflags = { "-Llib", "-lmysqlcppconnx-static", "-lmysqlcppconn-static", "-lresolv", @@ -267,8 +276,8 @@ function install() -- THE STANDARD LIBRARY THIS IS BUILT AGAINST HAS TO MATCH THE CONSUMER'S. -- - -- CMake picks the system compiler below, so the static libs come out - -- against libstdc++ whatever the consumer uses. On the llvm leg, which + -- CMake picks the system compiler below, so on Linux the static libs come + -- out against libstdc++ whatever the consumer uses. On the llvm leg, which -- links libc++, the member then fails at link with the libstdc++ half of -- its own dependency undefined: -- @@ -282,13 +291,12 @@ function install() -- 1. MEASURED. The probe below logged `MCPP_CXX_STDLIB=nil` on the llvm -- leg (mcpplibs/mcpp-index#392, `workspace (linux llvm 0/4)`), and -- the link failed exactly as before. - -- 2. THE ONLY SETTER is `src/build/build_program.cppm` (`e.emplace_back - -- ("MCPP_CXX_STDLIB", env.cxxStdlib)`) -- mcpp exports it when it runs - -- a BUILD PROGRAM. An xlings install hook is not that. - -- 3. THE CALL CARRIES NOTHING ELSE either: `make_xlings_env` builds an - -- `xlings::Env` of `{binary, home, projectDir}`, and - -- `install_packages` is invoked with `XLINGS_HOME` and PATH. No - -- toolchain, no compiler, no stdlib crosses that boundary. + -- 2. BY CONSTRUCTION, NOT BY OMISSION. mcpp 2026.9.12.2 emits + -- MCPP_CXX_STDLIB to a dependency's install hook, and it is empty + -- there: mcpp resolves the toolchain after the dependency graph, + -- because a package in the graph may supply a target-side layer, so no + -- standard library exists yet when this hook runs + -- (mcpp-community/mcpp#613, measured by its tests/e2e/648). -- -- So neither route is reachable from HERE. `llamacpp` refuses a libc++ -- toolchain by name with `mcpp::cxx_stdlib()`, but that lives in its @@ -300,17 +308,17 @@ function install() -- before the linker says it: these are STATIC libraries built by CMake -- with the system compiler, so `std::__cxx11::` and friends cross the -- boundary into the consumer. Consuming them from a libc++ toolchain does - -- not work and cannot be made to work from inside this hook. Tracked as - -- mcpp-community/mcpp#613 (install hooks need the consumer's stdlib); - -- until then - -- `validate.yml` keeps this member off the llvm leg, with the same reason - -- written there. + -- not work and cannot be made to work from inside this hook. The + -- descriptor states it instead (`requires` in the per-platform tables of + -- the mcpp segment above), and + -- `validate.yml` keeps this member off the llvm leg, because the refusal + -- follows this hook's source build and the leg would spend the build to + -- reach an answer it already knows. -- - -- The probe stays. It costs one log line, it is the evidence for point 1, - -- and the day mcpp does pass the variable through, this line reports it - -- and the fix becomes a three-line change directly below. + -- The probe stays. It costs one log line and is the evidence for points 1 + -- and 2: nil from an mcpp older than 2026.9.12.2, empty from a newer one. hook_log("MCPP_CXX_STDLIB=" .. tostring(os.getenv("MCPP_CXX_STDLIB")) - .. " (expected nil; see the comment above)") + .. " (expected nil or empty; see the comment above)") if os.host() == "macosx" then -- Connector 在 project() 前启动 bootstrap CMake；必须通过环境变量 -- 将最低系统版本同步给 bootstrap 及其后续的内置依赖构建。