> When --host is given, we should not just assume we've got a cross
> compiler. Instead, we test the compiler we've got, and decide whether
> it's a cross compiler or not.
...
> The only concessions for backward compatibility we're making is that
> --host alone will cause a cross-compilation situation to be
> auto-detected, even though $build will be set to host, not to
> `config.guess'. But, as I said, there'd be no way to guess --build
> correctly, so we might as well bail out when we detect a cross
> compiler and --build wasn't specified.
...
> > If you are dead set on reverting to the
> > old behavior
>
> I'm not. I want both behaviors, so that people can make the
> conversion when it is more convenient for them, and we can have some
> time for the world to adapt to the change. And I hope my patch shows
> it is possible to deliver that.
...
> Sure: just run `configure --host=i386-mingw32'. It will work, just as
> before. The problem is that, just as before, you won't have `--build'
> set properly.
>
> You can set:
>
> % b=--build=`config.guess`
>
> and run:
>
> % ./configure $b --host=i386-mingw32
>
> There's no way for configure to correctly guess the build platform, in
> general, when it's told to use a cross compiler.
That is still really lame. Why can't we just switch the value
of $build over to the output of config.guess for the build
system when we try to detect a cross compiler and the
resulting executable can not be run? That would give
us the "best of both worlds" solution that you
mentioned. That would let me run the following
and have it detect the build and host system.
./configure --host=i386-mingw32
It is not as clean as the original solution
but it should maintain backward compatibility
and let people use both the old and new
semantics.
Mo DeJong
Red Hat Inc
