Hi
On Thu, Oct 13, 2022 at 3:50 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > 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__) > > Weird, it should have been introduced with commit e03b56863d ("Replace config-time define HOST_WORDS_BIGENDIAN"), and it's part of commit 519655970 ("Move HOST_LONG_BITS to compiler.h")...probably my bad with a rebase. -- Marc-André Lureau
