Re: cross compiling and autoconf's host vs build (vs target)

Hi Andrew,

I saw both this post and a follow-up post of yours regarding the same
topic. The reason for the late reply is that last Thursday and Friday
were Thanksgiving holidays in the US.

On Thu, Nov 26, 2015 at 10:49 AM, Andrew Cagney <[email protected]> wrote:
> The autoconf 2.13 to 2.50 transition, er, "cleaned up" cross
> compilation and, in the process, "clarified" the meaning of "host",
> "build" and "target".
>
> For instance, I can specify:
>
> ./configure --host=m68k-uclinux-linux --build=i686-pc-linux-gnu
> --target=m68k-uclinux-linux ...
>
> to cross compile npsr (--host and host!=build trigger the cross compile):
>
> checking build system type... i686-pc-linux-gnu
> checking host system type... m68k-uclinux-linux-gnu
> checking target system type... m68k-uclinux-linux-gnu
>
> However, for nspr, this didn't work.  Looking at configure.in, it
> seems to still have traces of the old 2.13 conventions (mixing "$host"
> and "$build").  For instance:
>
> -if test "$target" != "$host"; then
> -    echo "cross compiling from $host to $target"
> +if test "$target" != "$build"; then
> +    echo "cross compiling from $build to $target"
>
> which is changed by the below patch.
>
> However, tread carefully, I find the way this all hangs together
> quickly gets messy and confusing (details are in "Hosts and
> Cross-Compilation" section in autoconf's documentation).

Thank you for the patch. It is a known problem that NSPR's
configure.in script doesn't follow the current autoconf convention for
cross compilation. I noticed this when I ported configure.in from
autoconf 2.13 to 2.69. There are two reasons I decided to not change
it.

1) As you may have noticed, there is some code in configure.in that
seems to detect cross compilation using "nonstandard" or enhanced
checks -- the code that sets the |cross_compiling| and |CROSS_COMPILE|
variables. I don't understand that code, so I avoided changing it.

2) Mozilla's top-level configure.in script follows the same
convention. Although NSPR is a stand-alone library, it is often
associated with Mozilla, so I thought it would be good to be
consistent.  (Mozilla's configure.in can invoke a sub-configure that
follows a different convention, so NSPR doesn't need to be
consistent.)

I am not familiar with cross compilation. The best people to talk to
about this issue would be Mozilla's build system experts, such as Mike
Hommey and Ted Mielczarek. I don't know if they read this newsgroup
regularly. I suggest you file a bug report and attach your patch to
it: https://bugzilla.mozilla.org/enter_bug.cgi?product=NSPR

Thanks,
Wan-Teh