Closed Bug 501436 Opened 15 years ago Closed 15 years ago

move Gecko 1.9.3 tinderboxes and production builds to Mac OS X 10.5, 10.5 SDK, gcc-4.2

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jaas, Assigned: jaas)

References

Details

(Whiteboard: [fixed in mozilla1.9.3a1])

Attachments

(2 files)

fix v1.0
3.71 KB, patch
ted
: review+
Details | Diff | Splinter Review
(Bv1) Fix comment too [Checkin: Comment 38]
1.07 KB, patch
ted
: review+
Details | Diff | Splinter Review 
Gecko 1.9.2 should not support Mac OS X 10.4. We should move 1.9.2 builds and tinderboxen to Mac OS X 10.5 using the 10.5 SDK and gcc-4.2.
Flags: blocking1.9.2?
Releng - of course, please get proper approval from drivers before doing this.
Do we want to use gcc-4.2 or newer on linux as well?
We should only do that if we decide that we no longer support compiling with lower gcc versions.  In particular, we have some code around (not checked in yet) that will compile with gcc 4.2 but not 4.0...
I assume bz is talking about Linux...
Yes, indeed.
(In reply to comment #0)
> Gecko 1.9.2 should not support Mac OS X 10.4.

Has this been agreed upon yet? I know there was a large thread about it, but I do not know what the conclusion was.

> We should move 1.9.2 builds and
> tinderboxen to Mac OS X 10.5 using the 10.5 SDK and gcc-4.2.

We're already running OS X 10.5.2 with Xcode 3.1. Looks like this already gives us the 10.5 SDK and gcc-4.2 - we'll just have to switch the paths, or something.


> Releng - of course, please get proper approval from drivers before doing this.

I think the onus is on you to get agreement on the general plan. We'll work out the details such as when we make the switch.
(In reply to comment #2)
> Do we want to use gcc-4.2 or newer on linux as well?

Regardless of the answer to this question let's keep this bug focused on OS X. If we do want to push Linux forward let's track that in a different bug.
Hm. I worry that this bug is making an assumption about the date on which we plan on shipping products off of mozilla-1.9.2. As context changes around our upcoming product deliveries (Fennec, f.e.) I'm not sure that the tacit assumption that 1.9.2 = Firefox 3.next is actually true.

Josh: is the pressure here time based, or just making sure that the Tinderboxes are matching the primary user platform that we're supporting? What's the breakdown of 10.4/10.5 users we have on 3.5?
This move only affects a Mac OS X release - not very relevant for a Fennec release.

I was originally operating on the assumption that we would not ship based on Gecko 1.9.2 until at least January or February of 2010, 4-5 months after 10.6 ships.

I don't know the current OS breakdown for 3.5 because the stats system hasn't been updated for 3.5 afaict.
(In reply to comment #0)
> Gecko 1.9.2 should not support Mac OS X 10.4. We should move 1.9.2 builds and
> tinderboxen to Mac OS X 10.5 using the 10.5 SDK and gcc-4.2.

Moving builds to the 10.5 SDK need not mean we don't run on 10.4 any more; as long as it is reasonably possible, we should try to maintain compatibility by testing for 10.5-specific features at runtime before using them.

There's (at least) one known issue with running 10.5-created builds on 10.4, see bug 423691, but it looks like we have a possible workaround for that.

So I'd like to see us switch SDKs, and relegate 10.4 to some kind of "less-supported" status, but keep some 10.4 tinderboxen so that we can tell when we do break compatibility - and can then assess the cost/benefit of fixing the breakage, not doing the new feature, or finally cutting off 10.4 users.
This bug is not about switching to the 10.5 SDK and staying on gcc-4.0. This is about making changes that would not allow us to run on 10.4, including a compiler upgrade.
Why does upgrading the compiler to gcc 4.2 prevent us running on 10.4? Surely that's an issue of what APIs we use, not which compiler.
Code produced by gcc-4.2 will not run on Mac OS X 10.4, it specifically says that in Apple gcc-4.2 documentation. I don't remember exactly why.
Hmmm. A bit of searching reveals that yes, this is not supported, though apparently there's no fundamental reason it can't be done; they just don't ship all the right support files. There's a workaround involving the SDK versions that shipped with gcc 4.2 Developer Preview 1, but we don't want to go there...

In that case, I think we should separate the issue of switching SDK versions from the issue of moving to gcc 4.2. That would let us consider a more incremental, perhaps less disruptive way forward. Are there compelling reasons we need the newer gcc at this point?
I agree that they should be separate issues, going to 4.2 and dropping 10.4 support is what this particular bug is about. The reason to go to gcc 4.2 is speed, it gives us significant performance improvements in my tests. I don't want to go over gcc 4.2 test results in this bug though, this doesn't seem like the place for that.

I don't want to rehash debates that happened on mozilla.dev.planning here. There is a lot of info about gcc-4.2 and other reasons for this particular move in those discussions.
Yes, I've read the debates on dev.planning. Note, though, that those discussions started from an assumption that 1.9.2 would appear in Q2 2010; but now it sounds like Gecko 1.9.2 and Firefox 3.6 will be released this fall. That might make a difference to the acceptability of cutting off 10.4 compatibility at this point.

In view of this, I've filed bug 504179, requesting a move to the 10.5 SDK even if we don't do the 10.4-breaking compiler change yet.
Moving this into Future until we have a concrete time when this should be done.
Component: Release Engineering → Release Engineering: Future
Flags: blocking1.9.2?
I have been working on our 64-bit port and 10.4 support is a real pain. I really think we need to do make this switch in Gecko 1.9.3. I updated the summary moving our target to 1.9.3.
Summary: move Gecko 1.9.2 tinderboxes and production builds to Mac OS X 10.5, 10.5 SDK, gcc-4.2 → move Gecko 1.9.3 tinderboxes and production builds to Mac OS X 10.5, 10.5 SDK, gcc-4.2
This work is approved to go ahead now. This does not reflect a final decision about 10.4 support in Gecko 1.9.3 but we are ready to take this step.

On a Mac OS X 10.5 tinderbox this means adding the following to our mozconfig:
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
ac_add_options --enable-macos-target=10.5

We should patch the build system to use gcc-4.2 when the macos-target is >= 10.5.

We'll also need a patch for breakpad, it will not build under the 10.5 SDK right now (bug 510920). There is a fix in the upstream Google code.

We may need to temporarily disable some tests and resolve them as quickly as possible. IIRC there are some failures due to Core Text, which would be enabled by this.
(In reply to comment #19)

> IIRC there are some failures due to Core Text, which would be enabled
> by this.

Core Text won't be enabled (on 32-bit builds) unless you also add
  ac_add_options --enable-coretext
to the mozconfig.
(In reply to comment #19)
> On a Mac OS X 10.5 tinderbox this means adding the following to our mozconfig:
> ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
> ac_add_options --enable-macos-target=10.5

This is a pretty small change. Please file dep bugs for everything below and we'll move ahead when they're resolved.
 
> We should patch the build system to use gcc-4.2 when the macos-target is >=
> 10.5.
> 
> We'll also need a patch for breakpad, it will not build under the 10.5 SDK
> right now (bug 510920). There is a fix in the upstream Google code.
(In reply to comment #19)
> This work is approved to go ahead now. This does not reflect a final decision
> about 10.4 support in Gecko 1.9.3 but we are ready to take this step.
> 
> On a Mac OS X 10.5 tinderbox this means adding the following to our mozconfig:
> ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk

Currently our nightly builds use the universal mozconfig, which specifies the SDK here:
http://mxr.mozilla.org/mozilla-central/source/build/macosx/universal/mozconfig#49

So you can just fix that on trunk. Also the GCC version is set there, so you should be able to just flip that as well.

> ac_add_options --enable-macos-target=10.5

I think if you're going to drop 10.4 support, you should just change the default value for this in configure:
http://mxr.mozilla.org/mozilla-central/source/configure.in#906

So the only changes here for RelEng should be changing the SDK/compiler on non-universal builds. (unittests, debug)
Depends on: 510920
Attached patch fix v1.0 — — Splinter Review 
When the trunk tboxes are ready this patch should switch everything to the 10.5 SDK and gcc-4.2. Non-universal builds will still use the system default compiler but we can take care of that later with bug 513353.
Assignee: nobody → joshmoz
Attachment #398703 - Flags: review?(ted.mielczarek)
Depends on: 514675
Attachment #398703 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 398703 [details] [diff] [review]
fix v1.0

Should be ok to land this now, right?

Still need another patch to change trunk mozconfigs to the 10.5 SDK:
http://hg.mozilla.org/build/buildbot-configs/file/c7d7c3824b84/mozilla2/macosx/mozilla-central/debug/mozconfig (for example)

bug 513353 will take care of switching everything else to gcc 4.2.
Comment on attachment 398703 [details] [diff] [review]
fix v1.0

         case "${target_cpu}" in
           x86_64)
             export MACOSX_DEPLOYMENT_TARGET=10.5
             ;;
           *)
-            export MACOSX_DEPLOYMENT_TARGET=10.4
+            export MACOSX_DEPLOYMENT_TARGET=10.5
             ;;

Oh, missed that on the first pass. Just ditch that case statement for now, since we want 10.5 everywhere.
Just thought of something: Since tracemonkey and places will end up getting this change via a merge, is it going to affect their ability to safely merge over to mozilla-1.9.2? (Are we even changing the compiler on those repos? I can't tell)
I don't think so, they cherry-pick patches for branches anyway. I doubt it will add any more pain to that process than already exists.
breakpad PPC bustage fix

http://hg.mozilla.org/mozilla-central/rev/9c3a70ea7acf
buildbot mozconfig changes

http://hg.mozilla.org/build/buildbot-configs/rev/56255997c17c
Filed bug 516799 on failing symlink unit test and disabled the test for now. I'm working on a fix now.
(In reply to comment #28)
> pushed to mozilla-central
> 
> http://hg.mozilla.org/mozilla-central/rev/594dd7f280fa

This check-in causes my local builds to break with the following error: 

checking for correct temporary object destruction order... no
configure: error: Your compiler does not follow the C++ specification for temporary object destruction order.
*** Fix above errors and then restart with               "make -f client.mk build"

I'm using XCode 3.1.2 on 10.5. Has this check-in changed the minimum version of XCode that we require or something? https://developer.mozilla.org/En/Mac_OS_X_Build_Prerequisites doesn't mention that if it did.
Ah, it seems to be down to the following line in my .mozconfig:

ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk

Changing that to:

ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk

Fixes things. I've updated https://developer.mozilla.org/En/Mac_OS_X_Build_Prerequisites , but it would be good for someone else to check my changes there.
could this have caused a Ts regression? it's in the range for bug 517915.
This caused a bit of a Ts regression but it was likely due to bug 517549, which this caused because it turned on expensive 10.5+ TIS calls by accident. That has been fixed and now Ts is much lower than it was before this bug.

This would not have caused a Ts regressions on other platforms, as discussed in the perf regression bug.
(In reply to comment #33)
> Ah, it seems to be down to the following line in my .mozconfig:
> 
> ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk
> 
> Changing that to:
> 
> ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
> 
> Fixes things. I've updated
> https://developer.mozilla.org/En/Mac_OS_X_Build_Prerequisites , but it would be
> good for someone else to check my changes there.

I got hammered by this change.  I'm stuck at a 10.4 capable machine for now and had been building my own using 10.4 with Xcode 2.5 until this patch landed about 9/15.  Trunk builds also stopped then ...

Now they have resumed but won't run for me.  I got steered to this thread so I've seen the bad news.

But you mention in the updated Mac OS X build prerequisites that it's still possible to build on 10.4.  My question is HOW?  I can reverse version numbers in the universal mozconfig and set my own in my custom mozconfig, but that doesn't do all that is needed.

Any ideas for a non-expert at programing?  Or is the answer that you need to modify the requirements further to state building is no longer possible for < 10.5 and running is no longer possible for < 10.5?

One more place to make these changes is in the Compatibility Matrix.  It goes to 10.5, but stops at 4.0 and doesn't show 10..6.

Thanks for any hints ...

                 Dale
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Depends on: 527657
Whiteboard: [fixed in mozilla1.9.3a1]
Attachment #428926 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 428926 [details] [diff] [review]
(Bv1) Fix comment too
[Checkin: Comment 38]


http://hg.mozilla.org/mozilla-central/rev/f6cf621d9244
Attachment #428926 - Attachment description: (Bv1) Fix comment too → (Bv1) Fix comment too [Checkin: Comment 38]
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: