On Thu, 13 Oct 2022 at 12:08, Daniel P. Berrangé <berra...@redhat.com> wrote: > > On Thu, Oct 13, 2022 at 11:39:34AM +0100, Peter Maydell wrote: > > On Thu, 13 Oct 2022 at 09:47, Michal Privoznik <mpriv...@redhat.com> wrote: > > > > > > When determining the endiandness of the target architecture we're > > > building for a small program is compiled, which in an obfuscated > > > way declares two strings. Then, we look which string is in > > > correct order (using strings binary) and deduct the endiandness. > > > But using the strings binary is problematic, because it's part of > > > toolchain (strings is just a symlink to > > > x86_64-pc-linux-gnu-strings or llvm-strings). And when > > > (cross-)compiling, it requires users to set the symlink to the > > > correct toolchain. > > > > > > Fortunately, we have a better alternative anyways. Since we > > > require either clang or gcc we can rely on macros they declare. > > > > > > Bug: https://bugs.gentoo.org/876933 > > > Signed-off-by: Michal Privoznik <mpriv...@redhat.com> > > > > If we can determine this just by looking at C macros, does > > this really need to be a configure test at all ? Paolo? > > We don't need to rely on CLang / GCC macros either, as this > is exposed by GLib > > $ grep BYTE_ORDER /usr/lib64/glib-2.0/include/glibconfig.h > #define G_BYTE_ORDER G_LITTLE_ENDIAN > > IOW, any code that needs to know can do one of: > > #if G_BYTE_ORDER == G_LITTLE_ENDIAN > > #if G_BYTE_ORDER == G_BIG_ENDIAN
It would be more consistent for configure to do this the same way that compiler.h does, though: #define HOST_BIG_ENDIAN (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) thanks -- PMM
