Closed Bug 323997 Opened 15 years ago Closed 15 years ago

TARGET_XPCOM_ABI not set in AIX builds

Categories

(Firefox Build System :: General, defect)

1.8 Branch
Other
AIX
defect
Not set
normal

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)

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?
OS: Other → AIX
Version: Trunk → 1.8 Branch
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 on attachment 208955 [details] [diff] [review]
Patch for firefox 1.5

cls, does that make sense to you?
Attachment #208955 - Flags: review- → review?(cls)
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?
Attachment #209346 - Flags: review? → review+
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?
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).
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: 15 years ago
Resolution: --- → FIXED
Flags: blocking1.8.0.2+
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+
Attachment #209346 - Flags: approval-branch-1.8.1+
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
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
Whiteboard: [nvn-dl]
Updated the MDC page to include the "ibmc" compiler.
Status: RESOLVED → VERIFIED
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"
Bug should be reopened
Attachment #333431 - Flags: review?(cls)
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-
(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 :-(
Attached patch reworked with cls' suggestions (obsolete) — Splinter Review
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 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?
Flags: blocking1.9.0.3?
Flags: blocking1.8.1.17?
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.
Opened Follow-up bug 450909
Attachment #333524 - Attachment is obsolete: true
Attachment #333524 - Flags: approval1.9.0.3?
Attachment #333524 - Flags: approval1.8.1.17?
Flags: blocking1.9.0.3?
Flags: blocking1.8.1.17?
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.