Closed Bug 607190 Opened 10 years ago Closed 9 years ago
Add recognition of 32-bit Linux/MIPS platforms when setting CPU
_ARCH to configure .in
User-Agent: Mozilla/5.0 (X11; U; Linux mips64; en-US; rv:22.214.171.124) Gecko/20101007 Gentoo Firefox/3.6.8 Build Identifier: http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/3.1.3/source/thunderbird-3.1.3.source.tar.bz2 enigmail fails to build due to the Thunderbird configure script not recognising "mipsel" as a valid CPU_ARCH. I suspect this would also prevent some extensions from working in Thunderbird itself. Attached is a patch that amends configure.in to recognise "mips" and "mipsel". When these are seen in OS_TEST, OS_ARCH is set to "mips", to indicate a 32-bit MIPS system. I'm not certain how to proceed with 64-bit targets (mips64 and mips64el, which can be either n32 or n64 ABI) but for now, this at least gets Thunderbird and its extensions working on MIPS o32. Reproducible: Always Steps to Reproduce: Attempt to compile Thunderbird extensions on Linux/MIPS (either big or little endian). Enigmail is known to trigger the bug. Actual Results: TARGET_XPCOM_ABI is unset, enigmail build script skips over that argument when calling genxpi, genxpi fails because the arguments are out-of-order. Expected Results: TARGET_XPCOM_ABI should be set to a valid configuration... e.g. mips-gcc3 is chosen with the attached patch.
This seems like a patch that should first go into the core mozilla-central configure, and then ported into Thunderbird's one later. I'll move this to a core component for now.
Assignee: nobody → redhatter
Product: Thunderbird → Core
QA Contact: build-config → build-config
Comment on attachment 485942 [details] [diff] [review] Add "mips" and "mipsel" to CPU_ARCH checks. The code changes look fine, the actual patch format is a bit wonky. r=me regardless
Attachment #485942 - Flags: review?(khuey) → review+
khuey's review carried over, patch just updated to reflect m-c.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b9
Theorically, TARGET_XPCOM_ABI may be used to provide several components/plugins in an extension. Which means you can provide an extension with both a component for linux x86-64 and linux x86... Here, you can't differentiate between mips and mipsel, which are obviously incompatible. Note the same might apply to arm/armel.
OS: Linux → Windows CE
For arm we explicitly check eabi and use oabi if it's not: http://mxr.mozilla.org/mozilla-central/source/configure.in#4078 so we generate like arm-eabi-gcc3
Indeed, the patch will need revisiting, but getting it to recognise MIPS at all is an important first step IMO. I wasn't sure what would be necessary elsewhere for "mipsel" to be recognised. A bit of monkey-see-monkey-do on my part, looking at how the other architectures were handled. mipsel and mips aren't that different in concept; just one is big-endian, the other little-endian. No different to arm vs armeb for that matter. How is armeb handled, it looks from the snippet in that diff that you just call it "arm"? I think the ABI tagging is a good idea too; i.e. mips & mipsel can refer to O32, then we can have mips-n32/mipsel-n32, and mips-n64/mipsel-n64. We can look into this once Thunderbird actually works at all on MIPS (last version to work properly was 1.5.x, early 2.0 only worked properly on mipsel but didn't work with IMAP on mips, latest crashes if you look at it funny on mipsel). BTW: Not sure why this got changed to Windows CE, this bug has absolutely nothing to do with that OS from Redmond. Changing it back for accuracy as these patches have _NOT_ been tested on Windows CE.
OS: Windows CE → Linux
If you look at where I linked, you'll see that we do an AC_TRY_COMPILE to check for the __ARM_EABI__ preprocessor macro.
You need to log in before you can comment on or make changes to this bug.