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-deps12.9.2, 3.11, amd64, rockylinux8, l4, latest-driver, oldest-deps13.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
- Install a C++ toolchain (
gcc-c++ / g++) in the affected test containers before the cvxpy step in ci/thirdparty-testing/.
- Constrain the cvxpy version to one that publishes wheels for the affected Python/arch combinations.
- 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).
Summary
The
thirdparty cvxpystep fails onoldest-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 failingwheel-tests-cuoptjobs includethirdparty cvxpyin their failed steps:12.9.2, 3.11, arm64, rockylinux8, a100, latest-driver, oldest-deps12.9.2, 3.11, amd64, rockylinux8, l4, latest-driver, oldest-deps13.3.0, 3.14, arm64, ubuntu26.04, gb300, latest-driver, latest-depsAlso present in the 2026-08-18 nightly (32104333527) on 2 of 12 jobs, so it is recurring rather than a one-off.
Error
Analysis
cvxpy ships a native
_cvxcoreextension. 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 theoldest-depspin, and py3.14 aarch64) no wheel matches, pip builds from sdist, andg++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
gcc-c++/g++) in the affected test containers before the cvxpy step inci/thirdparty-testing/.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
thirdpartynightly failures from the same run: the Pyomocuopt_direct.pyTypeError, and #1485 (JuMP SOC bridge segfault, reopened).