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