On 2022-07-27, anonymous <invalid.nore...@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