gh-89640: Hardcode WASM float word ordering as little endian

[erlend-aasland]

• Issue: configure script cannot detect float word ordering on linux #89640

[erlend-aasland]

cc. @hoodmane

[hoodmane]

Thanks for the help @erlend-aasland!

[hoodmane]

Any compliant implementation of webassembly is little endian:
https://webassembly.github.io/spec/core/binary/values.html#floating-point

I think that if someone forked the spec and invented "big endian wasm" but still called the target wasm32-???-??? that would be met with a lot of hostility by the webassembly folks. Only wasm32-emscripten should ever hit this branch though, so it might be a tiny bit better to match [*emscripten*] and then we'll find out if AX_C_FLOAT_WORDS_BIGENDIAN ever started failing to detect wasi correctly, however unlikely that might be.

If for some reason we don't want to hard code Emscripten, there is an option here:
autoconf-archive/autoconf-archive#316

[hoodmane]

One effect that this change had is that it will no longer raise the error:

Unknown float word ordering. You need to manually preset
ax_cv_c_float_words_bigendian=no (or yes) according to your system.

if the float word order does not match arm or wasm and AX_C_FLOAT_WORDS_BIGENDIAN returns undefined. I think we should consider doing this:

--- a/configure.ac
+++ b/configure.ac
@@ -5920,7 +5920,15 @@ AX_C_FLOAT_WORDS_BIGENDIAN(
                                 stored in ARM mixed-endian order (byte order 45670123)])],
            [wasm*], [AC_DEFINE([DOUBLE_IS_LITTLE_ENDIAN_IEEE754], [1],
                                [Define if C doubles are 64-bit IEEE 754 binary format,
-                                stored with the least significant byte first])])])
+                                stored with the least significant byte first])],
+           AC_MSG_ERROR[([
+
+Unknown float word ordering. You need to manually preset
+ax_cv_c_float_words_bigendian=no (or yes) according to your system.
+
+           ])]
+  )]
+)
 
 # The short float repr introduced in Python 3.1 requires the
 # correctly-rounded string <-> double conversion functions from

[erlend-aasland]

Good catch, @hoodmane! Yes, indeed we should. Would you like to propose a PR? I noticed you already did :)