TARGET_XPCOM_ABI changes needed for Mac universal binaries

RESOLVED FIXED in mozilla1.8final

Status

()

Core
XPCOM
P1
normal
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: Mark Mentovai, Assigned: bsmedberg)

Tracking

({fixed1.8.0.2, fixed1.8.1})

Trunk
mozilla1.8final
PowerPC
Mac OS X
fixed1.8.0.2, fixed1.8.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nvn-dl])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

11 years ago
ppc/x86 universal Mac packages will need attention where TARGET_XPCOM_ABI is used.  Some users of TARGET_XPCOM_ABI (update) need to know whether the running application is within a universal binary or not.
(Assignee)

Comment 1

11 years ago
As discussed on #camino, there are a couple issues here:

1) for software update, the ABI doesn't actually identify the build being shipped: we're  going to need another "update identifier". I'm going to morph this bug into the update issue.

2) for extension manager, the ABI value appears to be correct, but we have a problem that the "nsExtensionManager.js" file is preprocessed to contain the ABI value directly, instead of reading it from nsIXULRuntime. I'm going to file a separate bug about this.
(Reporter)

Comment 2

11 years ago
The new update identifier can be handled as in bug 323657.
Blocks: 323355
(Assignee)

Comment 3

11 years ago
Except of course that the update code is implemented in JS...
(Reporter)

Comment 4

11 years ago
I meant that we could XPCOMify the utility function I wrote for that bug.
(Reporter)

Comment 5

11 years ago
New patch on bug 323657, attachment 209377 [details] [diff] [review], lets you get universalness through an XPCOM interface.
(Reporter)

Comment 6

11 years ago
We should have something ready on this for the initial Universal release.
Flags: blocking1.8.0.2?
Renominate when you've got a working patch.
Flags: blocking1.8.0.2?
(Assignee)

Updated

11 years ago
Assignee: joshmoz → benjamin
(Assignee)

Updated

11 years ago
Priority: -- → P1
Target Milestone: --- → mozilla1.8final
(Assignee)

Updated

11 years ago
Depends on: 323657
(Reporter)

Comment 8

11 years ago
The isUniversalBinary attribute from bug 323657 has landed on the trunk.
(Assignee)

Updated

11 years ago
Blocks: 326917
(Assignee)

Comment 9

11 years ago
Created attachment 212233 [details] [diff] [review]
Darwin_gcc3-Universal, rev. 1
Attachment #212233 - Flags: superreview?(darin)
Attachment #212233 - Flags: review?(mark)
(Assignee)

Updated

11 years ago
Attachment #212233 - Flags: review?(bent.mozilla)

Comment 10

11 years ago
Comment on attachment 212233 [details] [diff] [review]
Darwin_gcc3-Universal, rev. 1

>Index: toolkit/mozapps/update/src/nsUpdateService.js.in
...
>+#if 0

Will this screw up line numbers in JS errors reported to the JS console?
If not, then why don't we fix the preprocessor to strip comments?
Attachment #212233 - Flags: superreview?(darin) → superreview+
(Assignee)

Comment 11

11 years ago
.js files automatically have //@line information added by the XUL preprocessor so reported line numbers are correct

And auto-stripping comments is very hard to do correctly; it would basically involve a full JS parser/tokenizer.
(Reporter)

Comment 12

11 years ago
Comment on attachment 212233 [details] [diff] [review]
Darwin_gcc3-Universal, rev. 1

This'll obviously need some minor server-side work too.
Attachment #212233 - Flags: review?(mark) → review+
(Assignee)

Comment 13

11 years ago
I don't think it will be minor, but it will be almost entirely on the tinderbox. Tt can/should be done at the same time the tinderbox automation of universals is done.
(Assignee)

Comment 14

11 years ago
Created attachment 212240 [details] [diff] [review]
Darwin_Universal-gcc3
Attachment #212240 - Flags: review?(bent.mozilla)
(Assignee)

Updated

11 years ago
Attachment #212233 - Attachment is obsolete: true
Attachment #212233 - Flags: review?(bent.mozilla)
Comment on attachment 212240 [details] [diff] [review]
Darwin_Universal-gcc3

Looks good, but I think it might be wise to stick a LOG() statement in the catch block indicating that the ABI is unknown. Then at least users could figure out why their Update Service was effectively dead. What do you think?

r=me, with or without the log message
Attachment #212240 - Flags: review?(bent.mozilla) → review+
(Assignee)

Comment 16

11 years ago
Created attachment 212248 [details] [diff] [review]
As checked in

Needed for branches to implement mac universal binaries, should be low-risk.
Attachment #212240 - Attachment is obsolete: true
Attachment #212248 - Flags: approval1.8.0.2?
Attachment #212248 - Flags: approval-branch-1.8.1?(darin)

Updated

11 years ago
Attachment #212248 - Flags: approval-branch-1.8.1?(darin) → approval-branch-1.8.1+
Flags: blocking1.8.0.2+
Comment on attachment 212248 [details] [diff] [review]
As checked in

approved for 1.8.0 branch, a=dveditz
Attachment #212248 - Flags: approval1.8.0.2? → approval1.8.0.2+
(Assignee)

Comment 18

11 years ago
Fixed on trunk, 1.8, 1.8.0
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.0.2, fixed1.8.1
Resolution: --- → FIXED

Updated

11 years ago
Whiteboard: [nvn-dl]
You need to log in before you can comment on or make changes to this bug.