Last Comment Bug 323328 - TARGET_XPCOM_ABI changes needed for Mac universal binaries
: TARGET_XPCOM_ABI changes needed for Mac universal binaries
: fixed1.8.0.2, fixed1.8.1
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: PowerPC Mac OS X
: P1 normal (vote)
: mozilla1.8final
Assigned To: Benjamin Smedberg [:bsmedberg]
: Nathan Froyd [:froydnj]
Depends on: 323657
Blocks: 323355 326917
  Show dependency treegraph
Reported: 2006-01-13 11:24 PST by Mark Mentovai
Modified: 2006-02-27 10:23 PST (History)
6 users (show)
dveditz: blocking1.8.0.2+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Darwin_gcc3-Universal, rev. 1 (6.71 KB, patch)
2006-02-17 10:22 PST, Benjamin Smedberg [:bsmedberg]
mark: review+
darin.moz: superreview+
Details | Diff | Splinter Review
Darwin_Universal-gcc3 (6.71 KB, patch)
2006-02-17 11:57 PST, Benjamin Smedberg [:bsmedberg]
bent.mozilla: review+
Details | Diff | Splinter Review
As checked in (6.81 KB, patch)
2006-02-17 13:10 PST, Benjamin Smedberg [:bsmedberg]
darin.moz: approval‑branch‑1.8.1+
dveditz: approval1.8.0.2+
Details | Diff | Splinter Review

Description Mark Mentovai 2006-01-13 11:24:53 PST
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.
Comment 1 Benjamin Smedberg [:bsmedberg] 2006-01-13 11:33:33 PST
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.
Comment 2 Mark Mentovai 2006-01-16 12:18:46 PST
The new update identifier can be handled as in bug 323657.
Comment 3 Benjamin Smedberg [:bsmedberg] 2006-01-16 12:30:16 PST
Except of course that the update code is implemented in JS...
Comment 4 Mark Mentovai 2006-01-16 13:54:14 PST
I meant that we could XPCOMify the utility function I wrote for that bug.
Comment 5 Mark Mentovai 2006-01-23 11:57:58 PST
New patch on bug 323657, attachment 209377 [details] [diff] [review], lets you get universalness through an XPCOM interface.
Comment 6 Mark Mentovai 2006-02-10 13:16:47 PST
We should have something ready on this for the initial Universal release.
Comment 7 Daniel Veditz [:dveditz] 2006-02-16 12:33:16 PST
Renominate when you've got a working patch.
Comment 8 Mark Mentovai 2006-02-17 08:23:42 PST
The isUniversalBinary attribute from bug 323657 has landed on the trunk.
Comment 9 Benjamin Smedberg [:bsmedberg] 2006-02-17 10:22:54 PST
Created attachment 212233 [details] [diff] [review]
Darwin_gcc3-Universal, rev. 1
Comment 10 Darin Fisher 2006-02-17 10:51:06 PST
Comment on attachment 212233 [details] [diff] [review]
Darwin_gcc3-Universal, rev. 1

>Index: toolkit/mozapps/update/src/
>+#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?
Comment 11 Benjamin Smedberg [:bsmedberg] 2006-02-17 11:06:08 PST
.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.
Comment 12 Mark Mentovai 2006-02-17 11:33:36 PST
Comment on attachment 212233 [details] [diff] [review]
Darwin_gcc3-Universal, rev. 1

This'll obviously need some minor server-side work too.
Comment 13 Benjamin Smedberg [:bsmedberg] 2006-02-17 11:35:43 PST
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.
Comment 14 Benjamin Smedberg [:bsmedberg] 2006-02-17 11:57:03 PST
Created attachment 212240 [details] [diff] [review]
Comment 15 Ben Turner (not reading bugmail, use the needinfo flag!) 2006-02-17 12:09:10 PST
Comment on attachment 212240 [details] [diff] [review]

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
Comment 16 Benjamin Smedberg [:bsmedberg] 2006-02-17 13:10:58 PST
Created attachment 212248 [details] [diff] [review]
As checked in

Needed for branches to implement mac universal binaries, should be low-risk.
Comment 17 Daniel Veditz [:dveditz] 2006-02-21 18:25:58 PST
Comment on attachment 212248 [details] [diff] [review]
As checked in

approved for 1.8.0 branch, a=dveditz
Comment 18 Benjamin Smedberg [:bsmedberg] 2006-02-22 09:03:14 PST
Fixed on trunk, 1.8, 1.8.0

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