bug#33711: configure --host=aarch64 produces x86-64 binary

[Mike Frysinger]

reassign 33711 autoconf
thanks

On 11 Dec 2018 22:07, Erik van Velzen wrote:
> I compiled https://github.com/json-c/json-c using the command `sh
> autogen.sh && ./configure --host=aarch64 && make`. Unexpectedly this
> creates an x64 binary.
> 
> The correct argument in my case is --host=aarch64-linux-gnu
> 
> I think this should be an error. Currently, there is only the output
> "checking for aarch64-gcc... no" but this does not abort. So the error
> is postponed until the binary is actually used.

compiler lookup is an autoconf macro (AC_PROG_CC).  automake isn't involved.
reassigning to the autoconf project for consideration.

care must be taken to not break the non-cross-compiling case, but that probably
might mean that trying to improve the UX without breaking existing valid flows
is impossible without being extremely fragile.  so as much as it sucks, this is
probably a "sigh, that's just the way it is" situation.

consider a multilib system:
* default ABI is x86_64 (64-bit) but x86 (32-bit) also works
* `gcc` supports both depending on compiler flags
* `./onfigure` will produce 64-bit binaries
* `./onfigure --host=x86_64` will produce 64-bit binaries, but there is no
  `x86_64-gcc` (if any exist, it'd be more like `x86_64-pc-linux-gcc`)
* `./configure --host=i686 CFLAGS='-m32'` will produce 32-bit binaries, but
  there is no `i686-gcc`

> If I give --host=gibberish I do get an error as expected:
> 
> "checking host system type... Invalid configuration `gibberish':
> machine `gibberish' not recognized"

this is coming from the config project [1].  it is responsible for parsing
the specified tuple to see if it resembles something reasonable.  giving it
gibberish is not reasonable, so it aborts.  but a bare cpu name like you
showed at the top is valid syntax.  it just doesn't expand the way you're
expecting.

[1] https://savannah.gnu.org/projects/config/
-mike

signature.asc
Description: PGP signature