muon uses uname() to power host_machine cpu/endian functions. This
breaks multilib as uname might report that system is x64, whereas
compiler might support only x86(e.g using -m32 option). To fix this
bug, muon should rely on compiler information(e.g by parsing
preprocessor output) than using uname().
would such improvement also be needed for cross compilation ?
@illiliti so to find them
- gcc :
gcc -dM -E -: __i386 or i386 (32 bits), __x86_64 or x86_64 (64 bits) (Windows (boths 32 and 64 bits), solaris 32 bits, linux 64 bits)- clang:
clang -dM -E -idem, not tested on solaris though- suncc: https://stackoverflow.com/questions/38318425/detect-xarch-option-in-the-preprocessor, so x86_64 or __x86_64
- vc++ or gcc/clang on Windows: _WIN64 for x86_64, _WIN32 for x86_64 and i686.
I've not tried with ARM compiler, i don't have any on Windows right now
For further reference, it is entirely impossible to detect X32 via uname. X32 is an ILP32 x86_64 userspace ABI and always runs on a regular x86_64 kernel (with X32 syscalls enabled).
The recommendation by Debian’s X32 porters is to check for both ILP32 and x86_64 macros to identify a X32 environment. This is based of the SysV AMD64 ABI (and afaict ILP macros were added in version 0.99.7), a copy of version 1.0 is linked below: https://cs61.seas.harvard.edu/site/pdf/x86-64-abi-20210928.pdf
Currently meson and afaik muon’s host_machine info can't identify an X32 environment anyway, but this also affects the built-in NASM support. On X32 NASM should be configured with
-felfx32but currently is instead configured with-felf64breaking the build for anything using NASM on X32.In general assembly might also need custom configuration for X32 and therefore the ability to identify a X32 env from host_machine to work correctly. But e.g. for libass setting the correct output format is the only thing needed to make X32 builds work.
I want to note that
-m32is not related to x32 at all. It will simply compile a 32‐bit x86 binary (even when running on x86‐64). The-mx32option is what is used to compile to x32.
On Thu, May 23, 2024 at 17:57:25 +0000, ~zamfofex wrote:
I want to note that
-m32is not related to x32 at all.I know, but the X32 case is a further point for why uname shouldn’t be used (exclusively at least).
If all you’re after is compiling ix86 binaries on a x86_64 host (with presumably an ix86 userspace, else it’d be cross-compilation), you can work around the current limitations as described here: https://todo.sr.ht/~lattis/muon/81#event-347332 (such a workaround is impossible for X32)