thirdparty cvxpy: build fails on oldest-deps/arm64 nightly configs — no wheel and no g++ in container

Summary

The thirdparty cvxpy step fails on oldest-deps / arm64 nightly configurations because pip cannot find a prebuilt cvxpy wheel for that Python/arch combination, falls back to building from source, and the test container has no C++ compiler installed.

This is an environment gap, not a cuOpt or cvxpy defect — no cvxpy test ever runs on these configs.

Observed in

Nightly run 32220613929 (main @ 1dbab9cf, 2026-08-19) — 3 of 12 failing wheel-tests-cuopt jobs include thirdparty cvxpy in their failed steps:

• 12.9.2, 3.11, arm64, rockylinux8, a100, latest-driver, oldest-deps
• 12.9.2, 3.11, amd64, rockylinux8, l4, latest-driver, oldest-deps
• 13.3.0, 3.14, arm64, ubuntu26.04, gb300, latest-driver, latest-deps

Also present in the 2026-08-18 nightly (32104333527) on 2 of 12 jobs, so it is recurring rather than a one-off.

Error

  Building wheel for cvxpy (pyproject.toml): finished with status 'error'
      ...
      running build_ext
      building '_cvxcore' extension
      g++ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -Icvxpy/cvxcore/src/ ... \
        -c cvxpy/cvxcore/python/cvxcore_wrap.cxx -o build/temp.linux-aarch64-cpython-311/...
      error: [Errno 2] No such file or directory: 'g++'
      [end of output]

  ERROR: Failed building wheel for cvxpy
ERROR: Failed to build one or more wheels
Failed to build cvxpy

Analysis

cvxpy ships a native _cvxcore extension. When a matching binary wheel exists, pip installs it and no compiler is needed — which is why most matrix entries pass. On the affected configs (notably py3.11 aarch64 at the oldest-deps pin, and py3.14 aarch64) no wheel matches, pip builds from sdist, and g++ is absent from the image.

Note the failure is silent in terms of coverage: the step fails at install time, so cvxpy integration is simply never exercised on these configurations.

Options

1. Install a C++ toolchain (gcc-c++ / g++) in the affected test containers before the cvxpy step in ci/thirdparty-testing/.
2. Constrain the cvxpy version to one that publishes wheels for the affected Python/arch combinations.
3. Explicitly skip the cvxpy step (with a logged notice) on configurations where no wheel exists, so the gap in coverage is visible rather than showing up as a build failure.

Option 1 is the most faithful to the intent of the step — it keeps cvxpy actually tested everywhere — at the cost of source-build time on those jobs. Option 3 is the cheapest but should log loudly; a silently skipped integration test is worse than a failing one.

Related

Filed alongside the other thirdparty nightly failures from the same run: the Pyomo cuopt_direct.py TypeError, and #1485 (JuMP SOC bridge segfault, reopened).