[mergify]

Every Linux CI job has been failing since qiskit 2.6.0 reached PyPI. Importing our extension raises cannot allocate memory in static TLS block from libgomp, so the whole suite errors out before a single test runs. macOS is unaffected.

glibc sizes the per-thread TLS block at startup and keeps only a small surplus for libraries dlopened afterwards that need initial-exec TLS. Every Python extension module arrives that way, so they all draw on that one surplus, and the library that fails is whichever asks last rather than whichever consumed the space — which is why the error names libgomp and not the actual cause.

qiskit 2.6.0's _accelerate grew from 736 to 1544 bytes of initial-exec TLS, leaving too little for the libgomp we pull in afterwards. The growth is matrixmultiply 0.3.11 enabling its AVX-512 kernels, which quadruple one thread-local scratch buffer. That path activates at rustc >= 1.89, and 2.6.0 also raised its MSRV to exactly that, so both changes had to land together.

This raises the surplus via GLIBC_TUNABLES. It goes in tox.ini rather than the workflows so local runs are covered too. passenv would only forward the variable when the caller already set it, which is no help in CI. Note that tox replaces setenv rather than merging it in a child environment, so the mpi env repeats the setting.

Measured on glibc 2.42, x86-64: a single later dlopen can claim 1664 bytes, so 2.6.0 clears it by roughly seven bytes once alignment is counted. A margin that thin is why the same build fails in one environment and passes in another. Preloading libgomp also works, but only for libgomp — it removes libgomp from the queue without enlarging the surplus, so anything else wanting initial-exec TLS stays exposed.

Reported upstream as Qiskit/qiskit#17213, with the measurements. Revert this once that is fixed.

---

This pull request was drafted by Claude Opus 5 under my guidance.

---

This is an automatic backport of pull request #64 done by [Mergify](https://mergify.com).