Should I add a link to the compliance table to the release note?

The free-threading wheel builds are failing with undefined symbol: __gxx_personality_v0. I guess the build is using gcc instead of g++, or it can use gcc ... -lstdc++. It is coming from here, where it explicitly asks for cython_language=cpp. Maybe a problem with meson? How did it work previously...

 E   ImportError: /tmp/pytest-of-root/pytest-0/popen-gw1/test_cython0/random/_examples/cython/build/extending_cpp.cpython-313t-x86_64-linux-gnu.so: undefined symbol: __gxx_personality_v0
  

Maybe something connected to mesonbuild/meson#14284 ?

Maybe something connected to mesonbuild/meson#14284 ?

I'd hope not, because that bug shouldn't be present in any release. The build output seems to show c++ is used, rather than cc:

  [8/9] c++ -Iextending_cpp.cpython-313t-x86_64-linux-gnu.so.p -I. -I.. -I/tmp/tmp.cFFLEoIa4p/venv/lib/python3.13t/site-packages/numpy/_core/include -I/opt/_internal/cpython-3.13.0-nogil/include/python3.13t -fvisibility=hidden -fvisibility-inlines-hidden -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -fPIC -MD -MQ extending_cpp.cpython-313t-x86_64-linux-gnu.so.p/meson-generated_extending_distributions.pyx.cpp.o -MF extending_cpp.cpython-313t-x86_64-linux-gnu.so.p/meson-generated_extending_distributions.pyx.cpp.o.d -o extending_cpp.cpython-313t-x86_64-linux-gnu.so.p/meson-generated_extending_distributions.pyx.cpp.o -c extending_cpp.cpython-313t-x86_64-linux-gnu.so.p/extending_distributions.pyx.cpp
  [9/9] c++  -o extending_cpp.cpython-313t-x86_64-linux-gnu.so extending_cpp.cpython-313t-x86_64-linux-gnu.so.p/meson-generated_extending_distributions.pyx.cpp.o -Wl,--as-needed -Wl,--allow-shlib-undefined -shared -fPIC -Wl,--start-group /tmp/tmp.cFFLEoIa4p/venv/lib/python3.13t/site-packages/numpy/random/lib/libnpyrandom.a /tmp/tmp.cFFLEoIa4p/venv/lib/python3.13t/site-packages/numpy/_core/lib/libnpymath.a -Wl,--end-group

Should I add a link to the compliance table to the release note?

That sounds useful, more people should know about that table and it is relevant here.

Super weird that it only seems to matter on the free-threaded builds. Let me know if you want me to look closer at this.

It's hard to compare with the tests on the most recent wheel build because it uses pytest-xdist. It's possible the test was being skipped before, though.

It is only happening in the manylinux_2_28 builds. I wonder if the compiler is subtly broken there?

Let me know if you want me to look closer at this.

@ngoldbaum how can I say no to such an offer?

with #28415 merged, the version of manylinux_2_28 will be bumped. It uses a gcc 14 toolchain instead of gcc 13. It might be worth rebasing/merging main to see if this helps with the failing test.

In g++ version 14 I see the symbol defined in libstc++ (and only there). Perhaps is was elsewhere before?

charris@fedora [numpy.git (main)]$ nm -D /usr/lib64/libstdc++.so.6 | grep personality
000000000001b1c0 T __gxx_personality_v0@@CXXABI_1.3

That seems to have fixed it. In it goes.

Unfortunately, It's not fixed. The last commit did not trigger the wheel builder workflow.
More info on the failure in #28570