Re: Need for --build with --host when cross-compiling ?

[Keith Marshall]

On 03/02/13 09:49, Yann Droneaud wrote:
> [Moving the discussion to address@hidden
> So to create a "valid" --build argument, I was going to use
> --build=`uname -p`-`uname -s` but its producing 'x86_64-Linux' which is
> not recognized by config.sub. I was surprised by the behavor and made
> patches to allow config.sub to recognize this string.

Rather than running uname yourself, and piecing it together, could you 
not let config.guess do that for you?  That should generate a build 
triplet which config.sub will recognise.

> Even if I think config.sub should be more liberal in its input, autoconf
> and ./configure script should probably be fixed to not require a --build
> option when cross-compiling.

I find that irritating too.  I've added this

 # We need the canonical representation of the intended host platform
 # identification triplet, from which to deduce the subsystem designator
 # in distributed tarball names.  (Note that we explicitly override any
 # user specified "build_alias", because autoconf gets upset if "host"
 # is specified without "build", and we need "host" if cross-compiling;
 # all we need in this case is "host" != "build", and we don't really
 # care what "build" is, but AC_CANONICAL_HOST gets very upset, when it
 # calls ${srcdir}/build-aux/config.sub, if the user specifies a short
 # form which it cannot resolve -- e.g. "--build=linux" will fail).
 #
   AC_CONFIG_AUX_DIR([build-aux])
   build_alias=`${srcdir}/build-aux/config.guess`
   AC_CANONICAL_HOST

fairly early in the configure.ac, (but after AC_INIT), for my current 
MinGW project, to circumvent it.