Last Comment Bug 372428 - firefox configure.in does not work currently with a 64 bit kernel and a full 32 bit userland
: firefox configure.in does not work currently with a 64 bit kernel and a full ...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: mozilla1.9alpha8
Assigned To: Petteri Räty
:
: Gregory Szorc [:gps]
Mentors:
: 385593 (view as bug list)
Depends on:
Blocks: 343975 388276
  Show dependency treegraph
 
Reported: 2007-03-02 14:11 PST by Petteri Räty
Modified: 2008-07-12 14:01 PDT (History)
4 users (show)
asqueella: blocking1.9?
asqueella: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch for configure.in to make it work. (1.71 KB, patch)
2007-03-02 14:13 PST, Petteri Räty
cls: review+
Details | Diff | Splinter Review

Description Petteri Räty 2007-03-02 14:11:42 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); fi; rv:1.8.1.2) Gecko/20070302 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); fi; rv:1.8.1.2) Gecko/20070302 Firefox/2.0.0.2

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[7]: *** [xptcinvoke_x86_64_linux.o] Error 1
Comment 1 Petteri Räty 2007-03-02 14:13:23 PST
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.
Comment 2 cls 2007-06-25 13:14:16 PDT
*** Bug 385593 has been marked as a duplicate of this bug. ***
Comment 3 Bill Gianopoulos [:WG9s] 2007-06-25 15:29:43 PDT
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
Comment 4 Bill Gianopoulos [:WG9s] 2007-06-25 15:31:46 PDT
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.
Comment 5 cls 2007-06-25 15:43:07 PDT
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?
Comment 6 Bill Gianopoulos [:WG9s] 2007-06-25 16:32:35 PDT
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 7 cls 2007-06-25 18:56:02 PDT
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.
Comment 8 Nickolay_Ponomarev 2007-07-14 15:00:27 PDT
Checking in configure.in;
/cvsroot/mozilla/configure.in,v  <--  configure.in
new revision: 1.1843; previous revision: 1.1842
done
Comment 9 Nickolay_Ponomarev 2007-07-14 15:58:12 PDT
Had to fix a typo in the patch, "OS_TEXT" instead of "OS_TEST".
Comment 10 Petteri Räty 2007-07-14 16:11:12 PDT
(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
Comment 11 Mike Hommey [:glandium] 2008-07-12 13:31:15 PDT
*** Bug 249579 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.