Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.3k
gh-109054: Don't use libatomic on cross-compilation#109211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
vstinner commentedSep 10, 2023
Should it be documented inhttps://docs.python.org/dev/using/configure.html? |
vstinner commentedSep 10, 2023
This PR should fix the 3 wasm32-emscripten buildbots. See: |
vstinner commentedSep 10, 2023
!buildbot wasm32-emscripten |
bedevere-bot commentedSep 10, 2023
🤖 New build scheduled with the buildbot fleet by@vstinner for commitbed957b 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
vstinner commentedSep 10, 2023
The "Configure host Python" step now saysno for libatomic, as expected, good!
|
hoodmane commentedSep 10, 2023
Thanks@vstinner! |
vstinner commentedSep 10, 2023
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. |
Uh oh!
There was an error while loading.Please reload this page.
configure no longer uses libatomic by default when Python iscross-compiled. The LIBATOMIC variable can be set manually in thiscase: ./configure LIBATOMIC="-latomic" (...)
bed957b to0a69b27Comparevstinner commentedSep 10, 2023
I wrote PR#109224 to document |
erlend-aasland commentedSep 11, 2023
LGTM! |
| ]])], | ||
| [ac_cv_libatomic_needed=no],dnl build succeeded | ||
| [ac_cv_libatomic_needed=yes],dnl build failed | ||
| [ac_cv_libatomic_needed=no]) dnl cross compilation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
We could have usedac_cv_libatomic_needed=n/a for a more accurate result message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Oh, I didn't know this value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Oh, I didn't know this value.
Actually, the value is up to you; it's not a magical GNU Autoconf value :) See docs forAC_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_CHECKINGfor message, thenAC_CACHE_VALwith thecache-id and commands arguments, andAC_MSG_RESULTwithcache-id.
In out case,cache-id isac_cv_libatomic_needed. Whatever we set it to will be displayed to the user at the end of the check (via the implicitAC_MSG_RESULT call). So if we setac_cv_libatomic_needed ton/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 thatconfigure actually checked whether libatomic was needed (and thatconfigure concluded it was not).
I think it may be worth it to adjust this message. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Oh, my suggestion is made moot by#109344
Uh oh!
There was an error while loading.Please reload this page.
configure no longer uses libatomic by default when Python is cross-compiled. The LIBATOMIC variable can be set manually in this case: