[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Earnie
Subject: Re: Bug#850329: autoconf tries to execute foreign binaries
Date: Mon, 21 Aug 2017 08:48:21 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]