gh-109054: Don't use libatomic on cross-compilation

[vstinner]

configure no longer uses libatomic by default when Python is cross-compiled. The LIBATOMIC variable can be set manually in this case:

./configure LIBATOMIC="-latomic" (...)

• Issue: ARM Raspbian 3.x fails to build _testcapi extension: undefined symbol: __atomic_fetch_or_8 #109054

[vstinner]

The LIBATOMIC variable can be set manually in this case: ./configure LIBATOMIC="-latomic" (...)

Should it be documented in https://docs.python.org/dev/using/configure.html?

cc @erlend-aasland

[vstinner]

This PR should fix the 3 wasm32-emscripten buildbots. See:

• gh-106213: Make Emscripten trampolines work with JSPI #106219 (comment)
• gh-109054: configure checks if libatomic is needed #109101 (comment)

[vstinner]

!buildbot wasm32-emscripten

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @vstinner for commit bed957b 🤖

The command will test the builders whose names match following regular expression: wasm32-emscripten

The builders matched are:

• wasm32-emscripten node (dynamic linking) PR
• wasm32-emscripten node (pthreads) PR
• wasm32-emscripten browser (dynamic linking, no tests) PR

[vstinner]

The "Configure host Python" step now says no for libatomic, as expected, good!

wasm32-emscripten node (dynamic linking) PR

checking whether libatomic is needed by <pyatomic.h>... no

wasm32-emscripten node (pthreads) PR

checking whether libatomic is needed by <pyatomic.h>... no

wasm32-emscripten browser (dynamic linking, no tests) PR

checking whether libatomic is needed by <pyatomic.h>... no

[hoodmane]

Thanks @vstinner!

[vstinner]

test_threading failed on Windows x64: it's an unrelated known bug, see: #108987 (I proposed a fix). I re-ran the Windows x64 job.

[vstinner]

I wrote PR #109224 to document LIBATOMIC and other configuration variables.

[erlend-aasland]

LGTM!

[erlend-aasland]

We could have used ac_cv_libatomic_needed=n/a for a more accurate result message.

[vstinner]

Oh, I didn't know this value.

[erlend-aasland]

Oh, I didn't know this value.

Actually, the value is up to you; it's not a magical GNU Autoconf value :) See docs for AC_CACHE_CHECK. The signature for that macro is:

AC_CACHE_CHECK (message, cache-id, commands-to-set-it)

Quoting the docs:

It calls AC_MSG_CHECKING for message, then AC_CACHE_VAL with the cache-id and commands arguments, and AC_MSG_RESULT with cache-id.

In out case, cache-id is ac_cv_libatomic_needed. Whatever we set it to will be displayed to the user at the end of the check (via the implicit AC_MSG_RESULT call). So if we set ac_cv_libatomic_needed to n/a, the user should see this when cross-compiling:

checking whether libatomic is needed by <pyatomic.h>... n/a

Currently, the user will see this when cross-compiling:

checking whether libatomic is needed by <pyatomic.h>... no

The "no" may lead the user to incorrectly assume that configure actually checked whether libatomic was needed (and that configure concluded it was not).

I think it may be worth it to adjust this message. What do you think?

[erlend-aasland]

Oh, my suggestion is made moot by #109344