User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:188.8.131.52) Gecko/2008120121 Firefox/3.0.5 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:184.108.40.206) 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.
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.
Component: Build Config → Build Config
Product: Firefox → Core
QA Contact: build.config → build-config
> 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.
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.
Sorry, typed too quickly. --build implies --target
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
(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.
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
--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)
You need to log in before you can comment on or make changes to this bug.