fix(mysql-connector-cpp): the hook cannot know the consumer's stdlib — measured, then stated

The previous commit on this branch asked a question: does MCPP_CXX_STDLIB
reach an xlings install hook? It shipped a probe that logged the answer
either way and applied `-stdlib=libc++` if the answer was yes.

The answer is no, and this commit replaces the conditional with what was
learned. Three independent levels agree:

  1. MEASURED. `MCPP_CXX_STDLIB=nil` on `workspace (linux llvm 0/4)`, and
     the link failed exactly as before.
  2. THE ONLY SETTER is `src/build/build_program.cppm` — mcpp exports it
     when it runs a BUILD PROGRAM. An install hook is not that.
  3. NOTHING ELSE CROSSES 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 standard library.

So neither of the two routes I had assumed were available actually is.
`llamacpp` refuses a libc++ toolchain with `mcpp::cxx_stdlib()`, but that
lives in its build program in its own repo; an inline descriptor has no
such place. And `[target.'cfg(...)']` self-gating has a platform axis and
no standard-library axis — a cfg selector is not a platform.

The probe stays. One log line, it is the evidence for point 1, and the
day mcpp passes the variable through it reports that and the fix becomes
three lines directly below it.

What the descriptor can do is stop being silent: it now states that these
are static libraries built with the system compiler, that `std::__cxx11::`
therefore crosses the boundary, and that a libc++ consumer cannot use them
— where a user reads it, rather than where the linker says it.

`validate.yml` keeps the member off the llvm leg, with the same reasoning
written at the point that does the skipping. That is in CI and not in a
descriptor for a reason worth saying out loud: the leg is the only layer
that knows which standard library is in play. SKIPPED, NOT MARKED GREEN —
the incompatibility is real for users on a libc++ toolchain; this stops CI
re-measuring a known answer, it does not claim the combination works.

The empty-shard message downstream said "No workspace member affected by
this change", which would now be false in the case this change creates:
`linux llvm 0/4` holds mysql-connector-cpp and nothing else, so skipping it
empties the shard. It now covers both cases and points at the line that
says which.

Co-authored-by: sunrisepeak <x.d2learn.org@gmail.com>

Author: Sunrisepeak

.github/workflows/validate.yml

@@ -1123,6 +1123,48 @@ jobs:
         shell: bash
         run: |
           mine='${{ fromJSON(needs.select.outputs.plan)[matrix.platform][format('{0}', matrix.shard)] }}'
+
+          # ── A member its toolchain cannot build, and why that lives HERE ──
+          #
+          # Members self-gate with `[target.'cfg(...)']` (see the workspace
+          # comment above), and that has a platform axis and no STANDARD
+          # LIBRARY axis -- a cfg selector is not a platform. So a member that
+          # cannot be built under libc++ has nowhere of its own to say so, and
+          # the leg is the only layer that knows which standard library is in
+          # play. That is the whole reason this list is in CI and not in a
+          # descriptor; it is not a convenience.
+          #
+          # `mysql-connector-cpp`: the package builds STATIC libraries with
+          # CMake and the system compiler, so `std::__cxx11::` crosses the
+          # boundary and a libc++ consumer fails at link:
+          #
+          #     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).
+          # Filed against mcpp; when the hook can see the consumer's stdlib,
+          # this entry comes out and the descriptor does the work instead.
+          #
+          # SKIPPED, NOT MARKED GREEN: the incompatibility is real for users on
+          # a libc++ toolchain. This stops CI from re-measuring a known answer
+          # every run; it does not claim the combination works.
+          if [ "${{ matrix.toolchain }}" = "llvm" ]; then
+            kept=""
+            for m in $mine; do
+              case "$m" in
+                mysql-connector-cpp)
+                  echo "skipping '$m' on the llvm leg: static libs are built" \
+                       "against the system stdlib; see the comment above" ;;
+                *) kept="$kept $m" ;;
+              esac
+            done
+            mine="${kept# }"
+          fi
+
           echo "MEMBERS=$mine" >> "$GITHUB_ENV"
           echo "shard ${{ matrix.shard }}/${{ matrix.shards }}: ${mine:-<none>}"
 
@@ -1191,7 +1233,9 @@ jobs:
           # optimise, and a local harness that differs from CI measures
           # something else.
           if [ -z "$MEMBERS" ]; then
-            echo "No workspace member affected by this change — nothing to test."
+            echo "No workspace member to test here: none affected by this" \
+                 "change, or every member of this shard was skipped on this" \
+                 "leg (the shard step above says which, and why)."
           else
             MCPP_TIMINGS="$PWD/timings.tsv" bash tests/run_members.sh $MEMBERS
           fi

pkgs/c/compat.mysql-connector-cpp.lua

@@ -276,29 +276,40 @@ function install()
     --     ld.lld: error: undefined symbol:
     --         std::__cxx11::basic_string<...>::_M_create(...)
     --
-    -- `llamacpp` refuses a libc++ toolchain by name with
-    -- `mcpp::cxx_stdlib()`, but that is a build-program API and this is an
-    -- inline descriptor with no build program. What an install hook CAN do is
-    -- read the variable that API reads. mcpp exports MCPP_CXX_STDLIB when it
-    -- runs a build program (src/build/build_program.cppm); whether it reaches
-    -- an xlings install hook is not documented either way, so this asks
-    -- rather than assumes, and RECORDS the answer either way.
+    -- AND THIS HOOK CANNOT KNOW WHAT THE CONSUMER'S IS. That was asked as a
+    -- question and has now been answered; the answer is no, at three levels:
     --
-    -- Absent, nothing changes: the build is what it was, and the hook log says
-    -- the variable was not visible -- which is the missing half of the
-    -- diagnosis if the llvm leg fails again.
-    local want_stdlib = os.getenv("MCPP_CXX_STDLIB")
-    hook_log("MCPP_CXX_STDLIB=" .. tostring(want_stdlib))
-    if want_stdlib == "libc++" and os.host() == "linux" then
-        -- -stdlib reaches the compile AND the link, which is what a mixed
-        -- build gets wrong: compiling against libc++ headers and linking
-        -- libstdc++ produces the same undefined symbols one layer later.
-        compiler = compiler
-            .. "-DCMAKE_CXX_FLAGS=-stdlib=libc++ "
-            .. "-DCMAKE_EXE_LINKER_FLAGS=-stdlib=libc++ "
-            .. "-DCMAKE_SHARED_LINKER_FLAGS=-stdlib=libc++ "
-        hook_log("building against libc++ to match the consumer")
-    end
+    --   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.
+    --
+    -- So neither route is reachable from HERE. `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,
+    -- and `[target.'cfg(...)']` self-gating has a platform axis and no
+    -- standard-library axis (a cfg selector is not a platform).
+    --
+    -- WHAT IS TRUE ABOUT THIS PACKAGE, stated plainly so a user reads it
+    -- 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
+    -- an mcpp issue (install hooks need the consumer's stdlib); until then
+    -- `validate.yml` keeps this member off the llvm leg, with the same reason
+    -- written there.
+    --
+    -- 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.
+    hook_log("MCPP_CXX_STDLIB=" .. tostring(os.getenv("MCPP_CXX_STDLIB"))
+             .. " (expected nil; see the comment above)")
     if os.host() == "macosx" then
         -- Connector 在 project() 前启动 bootstrap CMake；必须通过环境变量
         -- 将最低系统版本同步给 bootstrap 及其后续的内置依赖构建。