Re: Bug#850329: autoconf tries to execute foreign binaries

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: 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

On Sun, Aug 20, 2017 at 09:18:44PM +0200, Vincent Lefevre wrote:

> On 2017-08-20 11:01:28 -0700, Ben Pfaff wrote:
> > 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
> > (and quotes come from there):
> >
> >    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
> >       compiler:
> >
> >           "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,
> > because case #3 is deprecated:
> >
> >     "**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?

_______________________________________________
Autoconf mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|

Re: Bug#850329: autoconf tries to execute foreign binaries

Earnie Boyd
On 8/21/2017 2:21 AM, Ben Pfaff wrote:

> 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
>
> On Sun, Aug 20, 2017 at 09:18:44PM +0200, Vincent Lefevre wrote:
>> On 2017-08-20 11:01:28 -0700, Ben Pfaff wrote:
>>> 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
>>> (and quotes come from there):
>>>
>>>    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
>>>       compiler:
>>>
>>>           "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,
>>> because case #3 is deprecated:
>>>
>>>     "**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.

--
Earnie

_______________________________________________
Autoconf mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|

Re: Bug#850329: autoconf tries to execute foreign binaries

Keith Marshall-2
In reply to this post by Ben Pfaff
On 21/08/17 07:21, Ben Pfaff wrote:

>> 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.

--
Regards,
Keith


_______________________________________________
Autoconf mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/autoconf

0xBDA28E02.asc (3K) Download Attachment
signature.asc (853 bytes) Download Attachment