User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); fi; rv:184.108.40.206) Gecko/20070302 Firefox/220.127.116.11 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); fi; rv:18.104.22.168) Gecko/20070302 Firefox/22.214.171.124 The patch I am going to attach explains things. Reproducible: Always Steps to Reproduce: 1. Try to compile Firefox on a system running a 64 bit kernel and a 32 bit userland 2. 3. Actual Results: i686-pc-linux-gnu-g++ -o xptcinvoke_x86_64_linux.o -c -fvisibility=hidden -DMOZILLA_INTERNAL_API -DOSTYPE=\"Linux2.6\" -DOSARCH=\"Linux\" -DBUILD_ID=0000000000 -DEXPORT_XPTC_API -I../../../../../../dist/include/xpcom -I../../../../../../dist/include -I/usr/include/nspr -I./../.. -fPIC -DGENTOO_NSPLUGINS_DIR=\"/usr/lib/nsplugins\" -DGENTOO_NSBROWSER_PLUGINS_DIR=\"/usr/lib/nsbrowser/plugins\" -fno-rtti -fno-handle-exceptions -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -march=nocona -pipe -Wno-return-type -w -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -ffunction-sections -O2 -DGENTOO_NSPLUGINS_DIR=\"/usr/lib/nsplugins\" -DGENTOO_NSBROWSER_PLUGINS_DIR=\"/usr/lib/nsbrowser/plugins\" -DMOZILLA_CLIENT -include ../../../../../../mozilla-config.h -Wp,-MD,.deps/xptcinvoke_x86_64_linux.pp xptcinvoke_x86_64_linux.cpp xptcinvoke_x86_64_linux.cpp: In function 'nsresult XPTC_InvokeByIndex(nsISupports*, PRUint32, PRUint32, nsXPTCVariant*)': xptcinvoke_x86_64_linux.cpp:182: error: invalid register name for 'a4' xptcinvoke_x86_64_linux.cpp:183: error: invalid register name for 'a5' gmake: *** [xptcinvoke_x86_64_linux.o] Error 1
Created attachment 257070 [details] [diff] [review] Patch for configure.in to make it work. A patch to fix the problem. See the comments in the patch.
I tried a patch similar to this before I came up with the patch I attached to bug 385593. The problem I had with this approach is that every time I tried to define target to anything that did not have x86_64 in the cpu field, the build failed with the segment violation detailed here: https://bugzilla.mozilla.org/show_bug.cgi?id=385593#c4
That said, if it is actually possible to do a build with this patch, as I also consider it to be more correct, the environment variable settings and .mozconfig lines to make it work would be helpful.
I haven't played with any dual-arch setups, but IMO, if you want to build for the non-default arch, then you have to specify it to the build system (which may or may not treat it as a cross-compile). So passing --target=i686 should be the correct option. You should figure out why nsinstall is segfaulting. Did you try running an strace on the process? Or ldd to make sure that it's linking to the proper libs?
changing from the following environment variables: CFLAGS=-m32 CXXFLAGS=-m32 to these: CC='gcc -m32' CXX='c++ -m32' resulted in a successful compile using the patch in this bug. Since I like this patch better than mine, especially since the target build system now shows correctly when you do an about:buildconfig. I think this is the patch to go with. I am not sure why the CFLAGS CXXLFAGS method did not work, but that is another bug.
Comment on attachment 257070 [details] [diff] [review] Patch for configure.in to make it work. After a quick dig, it looks like HOST_PROGRAMS (e.g., nsinstall) don't use CFLAGS even when building natively. They use HOST_CFLAGS which will use the --enable-optimize=flags when building natively.
Checking in configure.in; /cvsroot/mozilla/configure.in,v <-- configure.in new revision: 1.1843; previous revision: 1.1842 done
Had to fix a typo in the patch, "OS_TEXT" instead of "OS_TEST".
(In reply to comment #9) > Had to fix a typo in the patch, "OS_TEXT" instead of "OS_TEST". > heh wonder why it worked on my computer with the typo