Closed
Bug 326772
Opened 20 years ago
Closed 20 years ago
compatibility.ini should include TARGET_OS_ABI
Categories
(Toolkit :: Startup and Profile System, defect)
Toolkit
Startup and Profile System
Tracking
()
RESOLVED
FIXED
People
(Reporter: mark, Assigned: mark)
Details
(Keywords: fixed1.8.0.2, fixed1.8.1, Whiteboard: [nvn-dl])
Attachments
(3 files)
|
5.75 KB,
patch
|
benjamin
:
first-review+
darin.moz
:
second-review+
benjamin
:
approval-branch-1.8.1+
dveditz
:
approval1.8.0.2+
|
Details | Diff | Splinter Review |
|
5.75 KB,
patch
|
Details | Diff | Splinter Review | |
|
5.67 KB,
patch
|
Details | Diff | Splinter Review |
compatibility.ini should somehow identify the last architecture used with a profile, to force component reregistration when using a single profile with multiple architectures. TARGET_XPCOM_ABI is well-suited to this task. Because it is also prudent to identify the host OS, TARGET_OS_ABI is an even better choice.
It is insufficient to only compare versions, bdates, and gecko paths because these values can be the same across builds for different architectures. My obvious motivation is Mac universal binaries, which share a version and bdate for a pair of architectures, are likely to be installed at the same path (or even run under both architectures on a single host natively and using translation), and are likely to be used with the same profile under both architectures.
This can also be a problem under other circumstances, too: consider a single profile being shared by a number of Unix variants, each with a gecko installation in /usr/local. TARGET_OS_ABI handles cases where, for example, multiple Unixish systems share a common TARGET_XPCOM_ABI such as x86-gcc3.
This should block the initial Mac universal release.
| Assignee | ||
Updated•20 years ago
|
Flags: blocking1.8.0.2?
Comment 1•20 years ago
|
||
I'm not sure this use-case is common enough to need to block anything, but it's probably easy to do. Assign to me if you like.
| Assignee | ||
Comment 2•20 years ago
|
||
Attachment #211495 -
Flags: second-review?(darin)
Attachment #211495 -
Flags: first-review?(benjamin)
Updated•20 years ago
|
Attachment #211495 -
Flags: second-review?(darin) → second-review+
Comment 3•20 years ago
|
||
Comment on attachment 211495 [details] [diff] [review]
Force reregistration when TARGET_OS_ABI changes
nit: in CheckCompatibility you can combine
if (NS_FAILED(rv) || !aOSABI.Equals(buf))
Attachment #211495 -
Flags: first-review?(benjamin) → first-review+
| Assignee | ||
Comment 4•20 years ago
|
||
Checked in on trunk.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
| Assignee | ||
Comment 5•20 years ago
|
||
Comment on attachment 211495 [details] [diff] [review]
Force reregistration when TARGET_OS_ABI changes
I'd like this on the branches to accomodate users who flip the Rosetta switch or carry their profile with them between ppc and x86 when migrating.
Attachment #211495 -
Flags: approval1.8.0.2?
Attachment #211495 -
Flags: approval-branch-1.8.1?(benjamin)
| Assignee | ||
Comment 6•20 years ago
|
||
I folded the aOSABI return into a single conditional, and did the same for aVersion.
Updated•20 years ago
|
Flags: blocking1.8.0.2? → blocking1.8.0.2+
Comment 7•20 years ago
|
||
Comment on attachment 211495 [details] [diff] [review]
Force reregistration when TARGET_OS_ABI changes
approved for 1.8.0 branch, a=dveditz for drivers
Attachment #211495 -
Flags: approval1.8.0.2? → approval1.8.0.2+
Updated•20 years ago
|
Attachment #211495 -
Flags: approval-branch-1.8.1?(benjamin) → approval-branch-1.8.1+
| Assignee | ||
Comment 8•20 years ago
|
||
This was checked in on 1_8 and 1_8_0. It accounts for an indentation change.
| Assignee | ||
Updated•20 years ago
|
Keywords: fixed1.8.0.2,
fixed1.8.1
Updated•20 years ago
|
Whiteboard: [nvn-dl]
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
You need to log in
before you can comment on or make changes to this bug.
Description
•