[RFC] bpo-34585: Don't do runtime test to get float byte order#9085
[RFC] bpo-34585: Don't do runtime test to get float byte order#9085benjaminp merged 1 commit intopython:masterfrom
Conversation
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. You can check yourself to see if the CLA has been received. Thanks again for your contribution, we look forward to reviewing it! |
|
That's a great idea and it should help Android builds, too! A minor issue is - I remember in CPython, changes to ./configure should be added to the commit if configure.ac is modified. |
|
This seems fine, but we should get a CLA. |
|
CLA sorted. |
|
Thanks for the PR. I agree we should probably look into not pretending to support ARM4. |
Support for cross-builds is added in python/cpython#9085
5 participants
Currently configure.ac uses AC_RUN_IFELSE to determine the byte order of doubles, but this silently fails under cross compilation and Python doesn't do floats properly.
Instead, steal a macro from autoconf-archive which compiles code using magic doubles (which encode to ASCII) and grep for the representation in the binary.
RFC because this doesn't yet handle the weird ancient ARMv4 OABI 'mixed-endian' encoding properly. This encoding is ancient and I don't believe the union of "Python 3.8 users" and "OABI users" has anything in. Should the support for this just be dropped too? Alternatively, someone will need to find an OABI toolchain to verify the encoding of the magic double.
https://bugs.python.org/issue34585