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
  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. #950 on the 3.14 branch makes the same change 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/38184242911. Examine the logs at this URL for more detail.}

[MilesCranmer]

Hi all, just confirming a human is behind this PR.

I ran into this through PythonCall.jl, which embeds Python in Julia and so is one of the rare users that needs libpython. (I maintain the pyjuliapkg and pyjuliacall feedstocks.)

My understanding of the core issue:

• When libpython was split out of python in [main] Split shared Python library to libpython #894, its output kept the C++ compiler in its build requirements but not python's ignore_run_exports_from for it.
• So libpython now requires libstdcxx >=15, even though the library links no C++ runtime.
• Environments that cap libstdc++ (e.g. Julia 1.10/1.12 via PythonCall/CondaPkg) therefore can't install libpython, and on 3.11 to 3.14 can't install current python builds either.

I believe this PR fixes that.

@isuruf since you opened #843 and merged #894, could you take a look at this as a follow-up? cc @h-vetinari

[h-vetinari]

@conda-forge-admin, please rerender