python.h setting HAVE_THREAD_LOCAL breaks numpy build #142163
Description
Currently NumPy will fail to build on some systems using CPython main with the following error:
FAILED: [code=1] numpy/_core/_multiarray_umath.cpython-315-darwin.so.p/meson-generated_scalartypes.c.o
cc -Inumpy/_core/_multiarray_umath.cpython-315-darwin.so.p -Inumpy/_core -I../numpy/_core -Inumpy/_core/include -I../numpy/_core/include -I../numpy/_core/src/common -I../numpy/_core/src/multiarray -I../numpy/_core/src/npymath -I../numpy/_core/src/umath -I../numpy/_core/src/highway -I/Users/goldbaum/.pyenv/versions/3.15-dev/include/python3.15 -I/Users/goldbaum/Documents/numpy/.mesonpy-9trjlyib/meson_cpu -fvisibility=hidden -fdiagnostics-color=always -DNDEBUG -Wall -Winvalid-pch -std=c11 -O3 -fno-strict-aliasing -ftrapping-math -DNPY_HAVE_CLANG_FPSTRICT -DNPY_HAVE_NEON_VFPV4 -DNPY_HAVE_NEON_FP16 -DNPY_HAVE_NEON -DNPY_HAVE_ASIMD -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework -idirafter/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework/Headers -DACCELERATE_NEW_LAPACK -DHAVE_CBLAS '-DBLAS_SYMBOL_SUFFIX=$NEWLAPACK' -DNPY_INTERNAL_BUILD -DHAVE_NPY_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -MD -MQ numpy/_core/_multiarray_umath.cpython-315-darwin.so.p/meson-generated_scalartypes.c.o -MF numpy/_core/_multiarray_umath.cpython-315-darwin.so.p/meson-generated_scalartypes.c.o.d -o numpy/_core/_multiarray_umath.cpython-315-darwin.so.p/meson-generated_scalartypes.c.o -c numpy/_core/_multiarray_umath.cpython-315-darwin.so.p/scalartypes.c
In file included from ../numpy/_core/src/multiarray/scalartypes.c.src:28:
../numpy/_core/src/multiarray/conversion_utils.h:116:22: error: unknown type name 'thread_local'
116 | extern NPY_NO_EXPORT NPY_TLS int evil_global_disable_warn_O4O8_flag;
| ^
../numpy/_core/include/numpy/npy_common.h:131:21: note: expanded from macro 'NPY_TLS'
131 | #define NPY_TLS thread_local
| ^
1 error generated.
You can see why that's happening by looking at npy_common.h and noting that it depends on HAVE_THREAD_LOCAL being set by NumPy's meson build configuration based on a configure-time check:
Since #140690 was merged, python.h now unconditionally sets HAVE_THREAD_LOCAL, breaking the logic in npy_common.h.
Maybe on the NumPy side we should be prepending macros that depend on configure-time checks with a NPY_ prefix to avoid issues like this but also numpy might not be the only library where HAVE_THREAD_LOCAL is load-bearing. I don't see anything besides Python and NumPy in a github search: https://github.com/search?q=HAVE_THREAD_LOCAL+language%3AC+python.h&type=code&p=2
cc @ZeroIntensity. Also h/t to @tacaswell for originally finding this, reporting it on Discord, and bisecting it.