475488 - The usage of --host and --target in Firefox's configure.in is wrong

Status: RESOLVED INCOMPLETE

(Firefox Build System :: General, defect)

Description

[Paolo Bonzini]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5

From Autoconf's manual:

`--build=BUILD-TYPE'
     the type of system on which the package is being configured and
     compiled.  It defaults to the result of running `config.guess'.

`--host=HOST-TYPE'
     the type of system on which the package runs.  By default it is the
     same as the build machine.  Specifying it enables the
     cross-compilation mode.

Firefox uses --host when it should use --build, and --target when it should use --host.  Note that --target is wrong because:

`--target=TARGET-TYPE'
     the type of system for which any compiler tools in the package
     produce code (rarely needed).  By default, it is the same as host.



Reproducible: Always

Steps to Reproduce:
1. Run "./configure --host=i686-pc-darwin9" on a PowerMac.

Actual Results:  
No cross compilation detected.

Expected Results:  
Mozilla should be cross compiled to Intel mac.

In general, the cross compilation setup code in configure.in seems unnecessarily complicated, mostly due to the above wrong assumption about --host/--target.

Comment 1

[(not currently active) Ted Mielczarek]

I suspect this is historical, but the autoconf 2.13 documentation matches what you say:
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=autoconf.texi;h=22a2ccd501a9731036f48248a10bd6f68b53034a;hb=refs/heads/autoconf-2-13-branch#l4191

The use of "host" and "target" in the way we do harkens back to 1999 apparently:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla&command=DIFF_FRAMESET&file=configure.in&rev2=1.443&rev1=1.442
I'm not sure if cls misread the autoconf docs, or just didn't care. (The build/host/target distinction has always been a bit confusing to me, since 'target' only actually matters if you're building a compiler.)

That being said, I don't think that breaking all of our existing cross-compiling users and churning our build system is worth the theoretical consistency with other configure systems.

Comment 2

[Paolo Bonzini]

> That being said, I don't think that breaking all of our existing
> cross-compiling users and churning our build system is worth the theoretical
> consistency with other configure systems.

The "problem" is that when you build cross binutils/gcc you need to pass --target, while when you build cross Mozilla you would need --host according to the Autoconf docs.  While it's "obvious" that the two cases are different (cross binutils run on your computer, cross Mozilla doesn't), I suppose the confusion it causes can be real.

So I see your point and I'd understand resolving this as WONTFIX.  However it's not just theoretical consistency; the inconsistency with GCC's build system, for example, is apparent.  It also means extra care for Autoconf maintenance.

Note that it _would_ be possible to support both conventions for a while.  The best approach, in my opinion, would be to fix the build system so that the correct terminology is used (and a lot of the ugly stuff around line 300 of configure.in would go away at the same time), while supporting usage of --target for backwards compatibility.

Comment 3

[Benjamin Smedberg]

Note that --host should imply --target, but not the other way around. We'd have to do some special kind of target->host copy, which I think involves hacking the guts of autoconf.

So if you'd like to try and provide a patch to that effect, Ted or I can review it. Otherwise I think this is WONTFIX.

Comment 4

[Benjamin Smedberg]

Sorry, typed too quickly. --build implies --target

Comment 5

[Paolo Bonzini]

I don't think I'll work on it anytime soon, but it shouldn't involve hacking the guts of autoconf.

I think SUSPENDED is the right resolution.

Comment 6

[cls]

(In reply to comment #1)
> I'm not sure if cls misread the autoconf docs, or just didn't care. (The
> build/host/target distinction has always been a bit confusing to me, since
> 'target' only actually matters if you're building a compiler.)

Sure, I'll take the blame for that since the vast majority of my cross-compile experience was with toolchains at that point.

> That being said, I don't think that breaking all of our existing
> cross-compiling users and churning our build system is worth the theoretical
> consistency with other configure systems.

Which is the same rationale as to why the configuration hasn't changed since the inconsistency was discovered years ago.  It'll take far less time to change the code than it would to change brainprints.

Comment 7

[Oleg Romashin (:romaxa)]

I see similar ffi cross compilation problem

My mozconfig has

ac_add_options --build=i686-linux-gnu
ac_add_options --host=arm-linux-gnueabi

and cross env detected properly in configure, nspr/configure, but not in js/configure.

This patch for a/js/src/configure.in

-if test "$target" != "$host"; then
+if test "$target" != "$host" -o -n "$CROSS_COMPILE"; then

helps to solve problem

Comment 8

[Mike Hommey [:glandium]]

--build and --host are the autoconf > 2.5 options.
The autoconf 2.13 options are --host and --target, with --host being the equivalent of autoconf 2.5's --build (confusing, huh?)
So, to cross compile, you need to do --host=i686-linux-gnu --target=arm-linux-gnueabi (and most of the time you only need --target)