Bug#850329: autoconf tries to execute foreign binaries

[Ben Pfaff]

I'm adding the autoconf mailing list. For more background, take a look
at the Debian bug log:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850329

This bug regards how Autoconf decides whether it's cross-compiling.
This is a somewhat tricky issue. The following is summarized from
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html
1. Without --host or --build, Autoconf aborts if it can't run the
binaries that the compiler produces. It assumes that's a
problem in the system configuration, such as a broken
compiler.
2. With --host and --build, Autoconf decides that it's
cross-compiling if the host and the build system are
different.
"If you specify both, and they're different, configure enters
cross compilation mode, so it doesn't run any tests that
require execution."
3. With --host, but not --build, Autoconf decides that it's
cross-compiling if it can't run a binary produced by the
"If you specify --host, but not --build, when configure
performs the first compiler test it tries to run an executable
produced by the compiler. If the execution fails, it enters
cross-compilation mode. This is fragile. Moreover, by the time
the compiler test is performed, it may be too late to modify
the build-system type: other tests may have already been
performed."
The issue here is what Autoconf should do in case #3, which is what wine
is doing. Is there a better way to detect whether the system can run a
binary, than to try to run the binary? Or is there a way to avoid the
broken dash behavior?

In case 3, can't Autoconf use the guessed value of BUILD, so that
it would be like case 2?

But I am a little concerned about whether we should do anything at all,
"**Do not rely on [case 3]**, as it will be removed in the near
future... Therefore, whenever you specify --host, be sure to
specify --build too."

As the --build value can be guessed, I think that it would be annoying
for the user to force him to use --build in case of cross-compilation.
IMHO, making case 3 like case 2 with the guessed value of BUILD (as
I've proposed above) would make sense. That would be the typical case
for cross-compilation, as in general, one builds on the machine where
one runs configure.

Hmm. I'm comfortable with the idea of trying to figure out some way to
avoid trying to execute binaries as if they were shell scripts. On the
other hand, while I don't personally object to changing this basic
Autoconf behavior, this is getting well into the territory where I'd be
uncomfortable proposing it myself. Does anyone on the autoconf mailing
list have thoughts?

[Earnie]

Post by Ben Pfaff
I'm adding the autoconf mailing list. For more background, take a look
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850329

This bug regards how Autoconf decides whether it's cross-compiling.
This is a somewhat tricky issue. The following is summarized from
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html
1. Without --host or --build, Autoconf aborts if it can't run the
binaries that the compiler produces. It assumes that's a
problem in the system configuration, such as a broken
compiler.
2. With --host and --build, Autoconf decides that it's
cross-compiling if the host and the build system are
different.
"If you specify both, and they're different, configure enters
cross compilation mode, so it doesn't run any tests that
require execution."
3. With --host, but not --build, Autoconf decides that it's
cross-compiling if it can't run a binary produced by the
"If you specify --host, but not --build, when configure
performs the first compiler test it tries to run an executable
produced by the compiler. If the execution fails, it enters
cross-compilation mode. This is fragile. Moreover, by the time
the compiler test is performed, it may be too late to modify
the build-system type: other tests may have already been
performed."
The issue here is what Autoconf should do in case #3, which is what wine
is doing. Is there a better way to detect whether the system can run a
binary, than to try to run the binary? Or is there a way to avoid the
broken dash behavior?

In case 3, can't Autoconf use the guessed value of BUILD, so that
it would be like case 2?

But I am a little concerned about whether we should do anything at all,
"**Do not rely on [case 3]**, as it will be removed in the near
future... Therefore, whenever you specify --host, be sure to
specify --build too."

As the --build value can be guessed, I think that it would be annoying
for the user to force him to use --build in case of cross-compilation.
IMHO, making case 3 like case 2 with the guessed value of BUILD (as
I've proposed above) would make sense. That would be the typical case
for cross-compilation, as in general, one builds on the machine where
one runs configure.

Hmm. I'm comfortable with the idea of trying to figure out some way to
avoid trying to execute binaries as if they were shell scripts. On the
other hand, while I don't personally object to changing this basic
Autoconf behavior, this is getting well into the territory where I'd be
uncomfortable proposing it myself. Does anyone on the autoconf mailing
list have thoughts?

With --host alone autoconf should assume it is a cross compile without
doing any further testing even if the guessed BUILD environment is
identical to the specified --host. This would aid in testing the cross
build before the package is published.

For a native build don't specify --host or specify --build the same as
--host. If the specified --build is different from the guessed --build
then perhaps a warning but that is questionable as some new system
cannot be guessed due to aging config files; maybe make that idea an
option to configure that can be specified by the user.

[Keith Marshall]

Post by Ben Pfaff

As the --build value can be guessed, I think that it would be annoying
for the user to force him to use --build in case of cross-compilation.
IMHO, making case 3 like case 2 with the guessed value of BUILD (as
I've proposed above) would make sense. That would be the typical case
for cross-compilation, as in general, one builds on the machine where
one runs configure.

Hmm. I'm comfortable with the idea of trying to figure out some way to
avoid trying to execute binaries as if they were shell scripts. On the
other hand, while I don't personally object to changing this basic
Autoconf behavior, this is getting well into the territory where I'd be
uncomfortable proposing it myself. Does anyone on the autoconf mailing
list have thoughts?

As a MinGW.org developer who uses LinuxMint Debian Edition as my primary
development platform, I've certainly found this autoconf behaviour to be
annoying, for some considerable time; (this annoyance is compounded by
config.sub, which forces me to specify the fully qualified build
triplet, for any project which uses AC_CANONICAL_SYSTEM, or even just
AC_CANONICAL_BUILD). Nonetheless, I do always specify both --build and
--host, because of the ambiguity introduced by specifying --host alone).

While I agree that this is an annoying (mis)feature of autoconf design,
as I see it, the ambiguity is triggered, not by any feature of whichever
shell is employed, but by the Linux kernel's own miscellaneous binaries
(binfmt_misc) support, which allows Windows binaries to be executed via
wine, providing it is installed, without it being explicitly specified:

$ uname -a
Linux ... 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13)
x86_64 GNU/Linux

$ file dist/staged/bin/gcc.exe
dist/staged/bin/gcc.exe: PE32 executable (console) Intel 80386
(stripped to external PDB), for MS Windows

$ dist/staged/bin/gcc.exe --version
gcc.exe (MinGW.org GCC-6.3.0-1) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.