Closed
Bug 323997
Opened 18 years ago
Closed 18 years ago
TARGET_XPCOM_ABI not set in AIX builds
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: ganesh.mozilla, Unassigned)
References
()
Details
(Keywords: fixed1.8.0.2, fixed1.8.1, Whiteboard: [nvn-dl])
Attachments
(2 files, 2 obsolete files)
818 bytes,
patch
|
cls
:
review+
|
Details | Diff | Splinter Review |
817 bytes,
patch
|
benjamin
:
review+
dveditz
:
approval-branch-1.8.1+
dveditz
:
approval1.8.0.2+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: http://developer.mozilla.org/en/docs/TARGET_XPCOM_ABI On AIX, the value of TARGET_XPCOM_ABI value is never set correctly. Issuing the following javascript command in the javascript console results in error NS_ERROR_NOT_AVAILABLE: Components.classes["@mozilla.org/xre/app-info;1"].getService(Components.interfaces.nsIXULRuntime).XPCOMABI Reproducible: Always Steps to Reproduce: 1. Start firefox 2. open the JavaScript Console 3. Evaluate the following JavaScript code: Components.classes["@mozilla.org/xre/app-info;1"].getService(Components.interfaces.nsIXULRuntime).XPCOMABI Actual Results: It results in error NS_ERROR_NOT_AVAILABLE. Expected Results: It should display "ppc-vacpp".
Attachment #208955 -
Flags: review?
Comment 2•18 years ago
|
||
Comment on attachment 208955 [details] [diff] [review] Patch for firefox 1.5 This is incorrect. The target compiler ABI is a concatenation of the CPU arch and the compiler ABI and is always set at http://lxr.mozilla.org/mozilla/source/configure.in#3534 You should test and set CPU_ARCH at http://lxr.mozilla.org/mozilla/source/configure.in#1031 and TARGET_COMPILER_ABI in http://lxr.mozilla.org/mozilla/source/configure.in#1262
Attachment #208955 -
Flags: review? → review-
(In reply to comment #2) > (From update of attachment 208955 [details] [diff] [review] [edit]) > This is incorrect. The target compiler ABI is a concatenation of the CPU arch > and the compiler ABI and is always set at > http://lxr.mozilla.org/mozilla/source/configure.in#3534 > > You should test and set CPU_ARCH at > http://lxr.mozilla.org/mozilla/source/configure.in#1031 > > and TARGET_COMPILER_ABI in > http://lxr.mozilla.org/mozilla/source/configure.in#1262 > Exactly, the target compiler ABI is the cancatenation of CPU_ARCH and TARGET_COMPILER_ABI. But the value of CPU_ARCH will depends on the value of OS_TEST. http://lxr.mozilla.org/mozilla/source/configure.in#1031 Initially the value of OS_TEST will be set with `uname -m`. http://lxr.mozilla.org/mozilla/source/configure.in#796 But in AIX, `uname -m` will return the machine ID and `uname -p` will display CPU Arch. if the OS_ARCH is AIX, I'm overriding OS_TEST value with `uname -p`.Now the OS_TEST will be set with 'powerpc' for AIX and the CPU_ARCH value will be set with 'ppc', http://lxr.mozilla.org/mozilla/source/configure.in#1036.
Comment 4•18 years ago
|
||
Comment on attachment 208955 [details] [diff] [review] Patch for firefox 1.5 cls, does that make sense to you?
Attachment #208955 -
Flags: review- → review?(cls)
Comment 5•18 years ago
|
||
I think I prefer 'ibmc' instead of 'vacpp' for the compiler name. The name VisualAge C++ has been changed to XL C/C++ and I think it makes more sense to just use ibmc for the IBM compiler on AIX.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 208955 [details] [diff] [review] Patch for firefox 1.5 r=cls with pkw's suggested change.
Attachment #208955 -
Flags: review?(cls) → review+
Attachment #209346 -
Flags: review?
Updated•18 years ago
|
Attachment #209346 -
Flags: review? → review+
Comment 8•18 years ago
|
||
Comment on attachment 209346 [details] [diff] [review] "updated patch with pkw's comments" Requesting approval for the 1.8 branch.
Attachment #209346 -
Flags: approval1.8.0.2?
Comment 9•18 years ago
|
||
Need to get this fixed and verified on the trunk: the approval guidelines for the 1.8.0 branch need two weeks on trunk before we can approve on branch (though it is a very low-risk patch).
Comment 10•18 years ago
|
||
Patch checked in to trunk: Checking in configure.in; /cvsroot/mozilla/configure.in,v <-- configure.in new revision: 1.1593; previous revision: 1.1592 done
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
Flags: blocking1.8.0.2+
Comment 11•18 years ago
|
||
Comment on attachment 209346 [details] [diff] [review] "updated patch with pkw's comments" approved for 1.8.0 branch, a=dveditz
Attachment #209346 -
Flags: approval1.8.0.2? → approval1.8.0.2+
Updated•18 years ago
|
Attachment #209346 -
Flags: approval-branch-1.8.1+
Comment 12•18 years ago
|
||
Fixed on 1.8.0 branch: Checking in configure; /cvsroot/mozilla/configure,v <-- configure new revision: 1.1492.2.17.2.5; previous revision: 1.1492.2.17.2.4 done Checking in configure.in; /cvsroot/mozilla/configure.in,v <-- configure.in new revision: 1.1503.2.15.2.6; previous revision: 1.1503.2.15.2.5 done
Keywords: fixed1.8.0.2
Comment 13•18 years ago
|
||
Fixed for 1.8.1: Checking in configure; /cvsroot/mozilla/configure,v <-- configure new revision: 1.1492.2.39; previous revision: 1.1492.2.38 done Checking in configure.in; /cvsroot/mozilla/configure.in,v <-- configure.in new revision: 1.1503.2.35; previous revision: 1.1503.2.34 done
Keywords: fixed1.8.1
Updated•18 years ago
|
Whiteboard: [nvn-dl]
Comment 14•18 years ago
|
||
Updated the MDC page to include the "ibmc" compiler.
Comment 15•15 years ago
|
||
This fix won't work for AIX 4.3.3 which is a supported configuration for GECKO 1.8.0 and 1.8.1 as there is no "uname -p" before AIX 5. Second, even on AIX 5.1 with "uname -p" there are machines with OS_TEST resulting in "rs6000" which are not comaptible with "ppc"
Comment 16•15 years ago
|
||
Bug should be reopened
Updated•15 years ago
|
Attachment #333431 -
Flags: review?(cls)
Comment 17•15 years ago
|
||
Comment on attachment 333431 [details] [diff] [review] fixes CPU_ARCH for RS/6000 w/o powerpc CPU also Is rs6000 the only type of AIX hardware supported by gecko? If not, then you shouldn't hardcode OS_TEST=rs6000. You should probably use ${target_cpu} instead.
Attachment #333431 -
Flags: review?(cls) → review-
Comment 18•15 years ago
|
||
(In reply to comment #17) > (From update of attachment 333431 [details] [diff] [review]) > Is rs6000 the only type of AIX hardware supported by gecko? If not, then you > shouldn't hardcode OS_TEST=rs6000. You should probably use ${target_cpu} > instead. There is only one default cpu architecture: the common mode, regardless if rs6000 or powerpc. The default for -O or -O2 is "-qarch=com" so the resulting binary runs on every machine regardless of the somewhat misleading build host cpu name. "-qarch=ppc" is incompatible with POWER or POWER2 cpu which are autoconfigured as rs6000-ibm-aix?.?.?.?, "-qarch=pwr" does not run on the PowerPC family cpu, which autoconfigures to powerpc-ibm-aix?.?.?.? So all hardware types should share the same CPU_ARCH because there is only one XPCOMABI "ppc-ibmc" as long as the default compiler's cpu target is the common mode. I will evaluate $(target_cpu) on both a rs6000 and powerpc build host and report later, my build hosts are quite slow machines :-(
Comment 19•15 years ago
|
||
Now XPCOMABI is set also on AIX 4.3.3 and also on machines with TARGET_CPU=rs6000
Attachment #333431 -
Attachment is obsolete: true
Attachment #333524 -
Flags: review?(cls)
Attachment #333524 -
Flags: review?(cls) → review+
Comment 20•15 years ago
|
||
Comment on attachment 333524 [details] [diff] [review] reworked with cls' suggestions Requesting approval for active branches. Risc: close to none. The patch affects the build configuration of AIX builds only. Verifed with tb 2.0.0.16, fx 2.0.0.16 and sm 1.1.11 with this bug's testcase and fx 3.0.1 is correctly configured. Porting to AIX5 is still in progress.
Attachment #333524 -
Flags: approval1.9.0.3?
Attachment #333524 -
Flags: approval1.8.1.17?
Updated•15 years ago
|
Flags: blocking1.9.0.3?
Flags: blocking1.8.1.17?
Comment 21•15 years ago
|
||
Can you please put this patch in a new bug? This bug has been verified fixed and already fixed on branches. Adding new patches two and a half years later make it hard to keep track of what's going on. You can carry over review in the new bug as well.
Comment 22•15 years ago
|
||
Opened Follow-up bug 450909
Updated•15 years ago
|
Attachment #333524 -
Attachment is obsolete: true
Attachment #333524 -
Flags: approval1.9.0.3?
Attachment #333524 -
Flags: approval1.8.1.17?
Updated•15 years ago
|
Flags: blocking1.9.0.3?
Flags: blocking1.8.1.17?
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•