Re: [sr #110687] AC_C_BIGENDIAN fails when cross-compiling with -std=c11 and -flto

[Nick Bowler]

On 2022-07-27, anonymous <INVALID.NOREPLY@gnu.org> wrote:
> Follow-up Comment #2, sr #110687 (project autoconf):
>
>> It appears to me that this is an issue with cross compilation and strict
> conformance mode (-std=c11), not with -flto.  Could you please report what
> happens, using the same cross-compilation toolchain, if you run the same
> configure command but using CFLAGS="-std=c11" LDFLAGS="" ?
>
> In that case (only -std=c11) everything works as expected.
>
> checking for unistd.h... yes
> checking whether byte ordering is bigendian... no
> configure: creating ./config.status
> config.status: creating issue618config.h
>
>
> The issue only occurs when using -flto.

This is not all that surprising.

Since Autoconf cannot run programs when cross compiling, Autoconf has
to use some other method.  One thing it tries is to use various
extensions found in the system header files, however this is obviously
not working with glibc when -std=c11 is used to disable extensions.

The other method inspects the code in compiled object files.  However,
-flto prevents generation of object files which are usable for this
purpose (as all the backend work is deferred to link time).  If you
use -ffat-lto-objects as well, the test should work again.

To fix this in Autoconf, probably just #defining _GNU_SOURCE or similar
directly in the test programs used by AC_C_BIGENDIAN can solve the
problem with the library header test.

To fix this in your package, I suggest just providing an action-if-unknown
argument to AC_C_BIGENDIAN, and adjust your package to work in that case
(usually this can be done easily with a runtime test).

In general, I don't recommend using strict standards-conformance modes
ever unless you are implementing standards-conformance test suites.
Such options typically cause more portability problems than they solve.

Cheers,
  Nick