Last Comment Bug 501436 - move Gecko 1.9.3 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...
Status: RESOLVED FIXED
[fixed in mozilla1.9.3a1]
:
Product: Release Engineering
Classification: Other
Component: Other (show other bugs)
: other
: All Mac OS X
: -- normal (vote)
: ---
Assigned To: Josh Aas
:
Mentors:
Depends on: 510920 514675 527657
Blocks: 516817 516858
  Show dependency treegraph
 
Reported: 2009-06-30 12:03 PDT by Josh Aas
Modified: 2013-08-12 21:54 PDT (History)
20 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
fix v1.0 (3.71 KB, patch)
2009-09-04 10:22 PDT, Josh Aas
ted: review+
Details | Diff | Splinter Review
(Bv1) Fix comment too [Checkin: Comment 38] (1.07 KB, patch)
2010-02-25 08:52 PST, Serge Gautherie (:sgautherie)
ted: review+
Details | Diff | Splinter Review

Description Josh Aas 2009-06-30 12:03:46 PDT
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.
Comment 1 Josh Aas 2009-06-30 12:05:46 PDT
Releng - of course, please get proper approval from drivers before doing this.
Comment 2 Chris AtLee [:catlee] 2009-06-30 12:06:39 PDT
Do we want to use gcc-4.2 or newer on linux as well?
Comment 3 Boris Zbarsky [:bz] 2009-06-30 13:24:26 PDT
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...
Comment 4 Josh Aas 2009-06-30 13:29:46 PDT
I assume bz is talking about Linux...
Comment 5 Boris Zbarsky [:bz] 2009-06-30 13:31:30 PDT
Yes, indeed.
Comment 6 Ben Hearsum (:bhearsum) 2009-07-07 03:21:59 PDT
(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.
Comment 7 Ben Hearsum (:bhearsum) 2009-07-07 03:22:33 PDT
(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.
Comment 8 Mike Beltzner [:beltzner, not reading bugmail] 2009-07-07 23:51:49 PDT
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?
Comment 9 Josh Aas 2009-07-08 07:16:22 PDT
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.
Comment 10 Jonathan Kew (:jfkthame) 2009-07-14 12:14:53 PDT
(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.
Comment 11 Josh Aas 2009-07-14 12:17:40 PDT
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.
Comment 12 Jonathan Kew (:jfkthame) 2009-07-14 12:33:10 PDT
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.
Comment 13 Josh Aas 2009-07-14 12:42:02 PDT
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.
Comment 14 Jonathan Kew (:jfkthame) 2009-07-14 13:06:01 PDT
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?
Comment 15 Josh Aas 2009-07-14 13:20:40 PDT
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.
Comment 16 Jonathan Kew (:jfkthame) 2009-07-14 14:18:18 PDT
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.
Comment 17 Chris AtLee [:catlee] 2009-07-20 10:56:08 PDT
Moving this into Future until we have a concrete time when this should be done.
Comment 18 Josh Aas 2009-08-11 21:07:41 PDT
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.
Comment 19 Josh Aas 2009-08-26 16:11:42 PDT
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.
Comment 20 Jonathan Kew (:jfkthame) 2009-08-26 16:32:29 PDT
(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.
Comment 21 Nick Thomas [:nthomas] 2009-08-26 16:34:52 PDT
(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.
Comment 22 Ted Mielczarek [:ted.mielczarek] 2009-08-26 16:48:25 PDT
(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)
Comment 23 Josh Aas 2009-09-04 10:22:22 PDT
Created attachment 398703 [details] [diff] [review]
fix v1.0

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.
Comment 24 Ted Mielczarek [:ted.mielczarek] 2009-09-15 05:34:21 PDT
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 25 Ted Mielczarek [:ted.mielczarek] 2009-09-15 05:39:52 PDT
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.
Comment 26 Ben Hearsum (:bhearsum) 2009-09-15 05:41:35 PDT
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)
Comment 27 Ted Mielczarek [:ted.mielczarek] 2009-09-15 06:09:59 PDT
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.
Comment 29 Josh Aas 2009-09-15 13:00:10 PDT
breakpad PPC bustage fix

http://hg.mozilla.org/mozilla-central/rev/9c3a70ea7acf
Comment 30 Josh Aas 2009-09-15 13:01:04 PDT
buildbot mozconfig changes

http://hg.mozilla.org/build/buildbot-configs/rev/56255997c17c
Comment 31 Josh Aas 2009-09-15 13:49:01 PDT
Filed bug 516799 on failing symlink unit test and disabled the test for now. I'm working on a fix now.
Comment 32 Jonathan Watt [:jwatt] 2009-09-16 08:56:54 PDT
(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.
Comment 33 Jonathan Watt [:jwatt] 2009-09-16 09:09:02 PDT
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.
Comment 34 Dietrich Ayala (:dietrich) 2009-09-21 23:16:01 PDT
could this have caused a Ts regression? it's in the range for bug 517915.
Comment 35 Josh Aas 2009-09-21 23:41:45 PDT
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.
Comment 36 dales 2009-10-25 11:20:22 PDT
(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
Comment 37 Serge Gautherie (:sgautherie) 2010-02-25 08:52:37 PST
Created attachment 428926 [details] [diff] [review]
(Bv1) Fix comment too
[Checkin: Comment 38]
Comment 38 Serge Gautherie (:sgautherie) 2010-03-03 03:12:55 PST
Comment on attachment 428926 [details] [diff] [review]
(Bv1) Fix comment too
[Checkin: Comment 38]


http://hg.mozilla.org/mozilla-central/rev/f6cf621d9244
Comment 39 Chris Cooper [:coop] 2010-03-11 14:17:58 PST
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.

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