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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Andrew Cagney
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).

Andrew

--- nspr-4.10.10/nspr/configure.in.orig    2015-11-26 10:15:40.436090828 -0500
+++ nspr-4.10.10/nspr/configure.in    2015-11-26 10:17:44.593081097 -0500
@@ -552,8 +552,8 @@
 dnl ========================================================
 dnl Checks for compilers.
 dnl ========================================================
-if test "$target" != "$host"; then
-    echo "cross compiling from $host to $target"
+if test "$target" != "$build"; then
+    echo "cross compiling from $build to $target"
     cross_compiling=yes

     case "$build:$target" in
@@ -582,7 +582,7 @@
 AC_PROG_CC

 dnl Reenter the conditional blocks after invoking AC_PROG_CC.
-if test "$target" != "$host"; then
+if test "$target" != "$build"; then
     if test -n "$USE_CPLUS"; then
         AC_CHECK_PROGS(CXX, $CXX "${target_alias}-g++" "${target}-g++", echo)
         unset ac_cv_prog_CXX
@@ -610,7 +610,7 @@
     _SAVE_CFLAGS="$CFLAGS"
     _SAVE_LDFLAGS="$LDFLAGS"

-    AC_MSG_CHECKING([for $host compiler])
+    AC_MSG_CHECKING([for $build compiler])
     AC_CHECK_PROGS(HOST_CC, $HOST_CC gcc cc /usr/ucb/cc, "")
     if test -z "$HOST_CC"; then
         AC_MSG_ERROR([no acceptable cc found in \$PATH])
@@ -621,10 +621,10 @@
     CFLAGS="$HOST_CFLAGS"
     LDFLAGS="$HOST_LDFLAGS"

-    AC_MSG_CHECKING([whether the $host compiler ($HOST_CC
$HOST_CFLAGS $HOST_LDFLAGS) works])
+    AC_MSG_CHECKING([whether the $build compiler ($HOST_CC
$HOST_CFLAGS $HOST_LDFLAGS) works])
     AC_TRY_COMPILE([], [return 0;],
         [AC_MSG_RESULT([yes])],
-        [AC_MSG_ERROR([installation or configuration problem: $host
compiler $HOST_CC cannot create executables.])] )
+        [AC_MSG_ERROR([installation or configuration problem: $build
compiler $HOST_CC cannot create executables.])] )

     CC=$_SAVE_CC
     CFLAGS=$_SAVE_CFLAGS
@@ -1163,9 +1163,9 @@
 fi

 dnl ========================================================
-dnl Override of system specific host options
+dnl Override of system specific build options
 dnl ========================================================
-case "$host" in
+case "$build" in
 *-mingw*|*-msys*)
     NSINSTALL=nsinstall
     ;;
_______________________________________________
dev-tech-nspr mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-nspr
Reply | Threaded
Open this post in threaded view
|

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

Wan-Teh Chang-3
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 <[hidden email]> 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
_______________________________________________
dev-tech-nspr mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-nspr
Reply | Threaded
Open this post in threaded view
|

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

Andrew Cagney
Sorry, yes I forgot US thanksgiving.  I've been trying to check if my
posts got through by looking at:
  https://groups.google.com/forum/#!forum/mozilla.dev.tech.nspr
but it seems to only show half of them. Now that I know that they are
getting out, I'll just ignore the list.

Anyway, like you suggest, I'll submit a PR.

Andrew


On 2 December 2015 at 12:19, Wan-Teh Chang <[hidden email]> wrote:

> 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 <[hidden email]> 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
_______________________________________________
dev-tech-nspr mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-nspr