René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"python.h setting HAVE_THREAD_LOCAL breaks numpy build","articleBody":"Currently NumPy will fail to build on some systems using CPython `main` with the following error:\n\n```\n FAILED: [code=1] numpy/_core/_multiarray_umath.cpython-315-darwin.so.p/meson-generated_scalartypes.c.o\n  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\n  In file included from ../numpy/_core/src/multiarray/scalartypes.c.src:28:\n  ../numpy/_core/src/multiarray/conversion_utils.h:116:22: error: unknown type name 'thread_local'\n    116 | extern NPY_NO_EXPORT NPY_TLS int evil_global_disable_warn_O4O8_flag;\n        |                      ^\n  ../numpy/_core/include/numpy/npy_common.h:131:21: note: expanded from macro 'NPY_TLS'\n    131 |     #define NPY_TLS thread_local\n        |                     ^\n  1 error generated.\n```\n\nYou 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:\n\nhttps://github.com/numpy/numpy/blob/fb0578d3973e926eee2e68ce9fd9996459b8534b/numpy/_core/include/numpy/npy_common.h#L128-L140\n\nhttps://github.com/numpy/numpy/blob/fb0578d3973e926eee2e68ce9fd9996459b8534b/numpy/_core/meson.build#L269-L294\n\nSince #140690 was merged, `python.h` now unconditionally sets `HAVE_THREAD_LOCAL`, breaking the logic in `npy_common.h`.\n\nMaybe 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\u0026type=code\u0026p=2\n\ncc @ZeroIntensity. Also h/t to @tacaswell for originally finding this, reporting it on Discord, and bisecting it.\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-142164\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/ngoldbaum","@type":"Person","name":"ngoldbaum"},"datePublished":"2025-12-01T23:06:34.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/142163/cpython/issues/142163"}