[3.14] libpython: drop the unused C++ compiler

[MilesCranmerBot]

Why

Every libpython build depends on libstdcxx >=15 on Linux (and libcxx on macOS), but the library never links a C++ runtime:

$ objdump -p lib/libpython3.15.so.1.0 | grep NEEDED    # libpython-3.15.0-hdc7f604_100_cp315, linux-64; 3.14.8 is the same minus libgcc_s
  NEEDED libm.so.6  libpthread.so.0  libdl.so.2  libutil.so.1  libgcc_s.so.1  libc.so.6  ld-linux-x86-64.so.2
$ otool -L lib/libpython3.15.dylib                     # osx-arm64
  @rpath/libpython3.15.dylib, /usr/lib/libSystem.B.dylib

The dependency is a run-export of {{ compiler('cxx') }} in the libpython output's build requirements. The python output already drops the same run-export with ignore_run_exports_from; libpython does not, yet its build compiles no C++: install_shared.sh only copies the library and, on macOS, calls $CC to make libpython3.dylib.

This blocks environments that cap the C++ runtime. CondaPkg.jl caps libstdcxx at the version bundled with Julia, which is below 15 for Julia 1.10 and 1.12. Under that cap:

• python + libpython is unsolvable (libpython 3.11.16 | ... | 3.15.0 would require libstdcxx >=15);
• python 3.13.16 and 3.14.8 are unsolvable, since they pin libpython exactly;
• python 3.15 is unusable for embedding, because it no longer pulls in libpython (Move libpython.so to another output #843).

PythonCall.jl needs to depend on libpython explicitly for 3.15 (JuliaPy/PythonCall.jl#838), and it can only do so once libpython stops requiring libstdcxx >=15.

Scope

Removes {{ compiler('cxx') }} from the libpython output's build requirements and bumps the build number. The C++ compiler stays in the test requirements, where cmake needs it. Same change as #949 on main, for 3.14.x builds. The 3.11, 3.12 and 3.13 branches have the same line; I'm happy to open those too.

Tradeoffs

None that I can find: nothing in the libpython build compiles C++.

Blast Radius

Only the libpython output's run requirements change. conda render of the linux-64 release config, before vs after, differs only in gxx leaving that output's build environment and libstdcxx >=15 leaving its run requirements; the python, libpython-static and other outputs keep the same requirements apart from ordering.

Verification

• conda render recipe -m .ci_support/linux_64_build_typereleasechannel_targetsconda-forge_mainfreethreadingno.yaml: libpython run requirements go from __glibc, libgcc >=15, libstdcxx >=15, python ... to __glibc, libgcc >=15, python ....
• The shared-library dependencies above were read from the published 3.15.0 and 3.14.8 packages.
• Solver behavior under libstdcxx <15 was checked with pixi on linux-64.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/38136483403. Examine the logs at this URL for more detail.}