Last Comment Bug 674655 - Drop references to ppc, switch x86 to using the 10.6 sdk
: Drop references to ppc, switch x86 to using the 10.6 sdk
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: unspecified
: x86_64 Mac OS X
: -- normal (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
: Gregory Szorc [:gps]
Mentors:
Depends on: 674440 674647
Blocks: universal-singlepass
  Show dependency treegraph
 
Reported: 2011-07-27 13:07 PDT by Rafael Ávila de Espíndola (:espindola) (not reading bugmail)
Modified: 2012-08-08 07:22 PDT (History)
20 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Drop references to ppc, switch x86 to using the 10.6 sdk (1.67 KB, patch)
2011-07-27 13:07 PDT, Rafael Ávila de Espíndola (:espindola) (not reading bugmail)
jaas: review+
ted: review+
Details | Diff | Splinter Review

Description Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2011-07-27 13:07:23 PDT
Created attachment 548881 [details] [diff] [review]
Drop references to ppc, switch x86 to using the 10.6 sdk

With these dependencies fixed, it is possible to build with the 10.6 sdk a binary that works on 10.5. We should do that to drop the dependency on the 10.5 sdk that is not included in newer versions of XCode.
Comment 1 Nick Thomas [:nthomas] 2011-07-27 13:15:22 PDT
This bug would be more appropriate in Core::Build Config, reviewed by josh (Josh Aas) or bsmedberg.
Comment 2 Cameron Kaiser [:spectre] 2011-08-04 08:23:46 PDT
For the record, we're still building PPC-compatible Firefoxes in TenFourFox-land. I can certainly back this out in our internal changesets, but I wanted to register the exception.
Comment 3 Josh Aas 2011-08-04 13:20:00 PDT
Comment on attachment 548881 [details] [diff] [review]
Drop references to ppc, switch x86 to using the 10.6 sdk

I'm fine with dropping PPC references but this changes the SDK for our i386 builds. Theoretically targeting 10.5 using the 10.6 SDK should be equivalent to using the 10.5 SDK but we've seen before that it is not. This makes me hesitant to mess with the SDK.
Comment 4 Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2011-08-04 13:23:17 PDT
Do you want me to split the patch in ppc and x86 parts?

What problems have you had in the past building with the 10.6 sdk? In the tests I did the only problem I had was the libcrypto version, but that dependency was already dropped.

Once the builds are running on 10.6 machines (but still with the 10.5 sdk), I will do full try runs to see if there are any other problems.
Comment 5 Josh Aas 2011-08-04 21:21:17 PDT
The problems we had in the past had to do with 10.3/10.4/10.5 SDKs. I don't recall the exact issues but the lesson learned was that Apple doesn't maintain the target-OS macros meticulously enough to completely accurately simulate an earlier SDK.

After thinking about it a bit more I'm not necessarily against trying it again but I want to make sure it is acknowledged that this is a non-trivial build change. I'd also like an r+ from Ted before we do this.

Don't bother splitting the patch.
Comment 6 Josh Aas 2011-08-04 21:28:33 PDT
Comment on attachment 548881 [details] [diff] [review]
Drop references to ppc, switch x86 to using the 10.6 sdk

Review of attachment 548881 [details] [diff] [review]:
-----------------------------------------------------------------

Before landing this please make sure that all of our i386 builds have "--enable-macos-target=10.5" set.
Comment 7 Josh Aas 2011-08-04 21:30:05 PDT
Comment on attachment 548881 [details] [diff] [review]
Drop references to ppc, switch x86 to using the 10.6 sdk

Might be best to add the "--enable-macos-target=10.5" stuff to "mozconfig.common" actually, in which case this patch will need to be modified.
Comment 8 Josh Aas 2011-08-04 21:33:19 PDT
Actually, that might be taken care of via a default in "configure.in".
Comment 9 Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2011-08-08 08:09:35 PDT
good point, the configure default is 10.5. Would you prefer if I removed the

ac_add_app_options i386 --target=i386-apple-darwin$DARWIN_VERSION

line?

I will not commit until the dependencies are fixed and a full test run is done one the bots.
Comment 10 Josh Aas 2011-08-08 08:25:19 PDT
(In reply to Rafael Ávila de Espíndola (:espindola) from comment #9)
> good point, the configure default is 10.5. Would you prefer if I removed the
> 
> ac_add_app_options i386 --target=i386-apple-darwin$DARWIN_VERSION
> 
> line?

I don't know enough about what that does and what the defaults are to make a decision on that.
Comment 11 Ted Mielczarek [:ted.mielczarek] 2011-08-08 09:51:22 PDT
Are we planning on moving our builds to a newer version of XCode? If not, why is this necessary? I don't see the problem with continuing to use the 10.5 SDK for our 10.5 builds until such point as we need to move to building on Lion.
Comment 12 Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2011-08-08 10:02:35 PDT
What I am trying to avoid is having to build with 2 different XCode versions. There are XCode versions that have SDKs for 10.5 and 10.6 and others that have it for 10.6 and 10.7.

Moving the 10.5 build to use the 10.6 sdk would allow us to move to an XCode with the 10.6 and 10.7 sdks and still support 10.5, 10.6 and 10.7 (including features that use new APIs if they can be checked at runtime).
Comment 13 Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2011-08-11 11:56:50 PDT
I was chatting with some chrome guys, and what they did is forward declare all the 10.7 APIs that they want.

The argument against using a new a new SDK was that it would make it easy for people to check in code that would depend on 10.6 only functions.

It is probably still a good idea to fix 674647, and drop the references to ppc, but I am not so sure about this one. I is probably up the devs using the new APIs, what do you prefer: having all new apis handy or the safety that you are not creating a 10.6 dependency accidentally?
Comment 14 Ted Mielczarek [:ted.mielczarek] 2011-08-12 08:55:41 PDT
Comment on attachment 548881 [details] [diff] [review]
Drop references to ppc, switch x86 to using the 10.6 sdk

Review of attachment 548881 [details] [diff] [review]:
-----------------------------------------------------------------

This is fine. Do you want to just merge this back into build/macosx/universal/mozconfig? The only reason I split it out into .common was to support both ppc/i386 and i386/x86_64 universal builds during the transition period.
Comment 15 Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2011-08-12 11:28:08 PDT
I can do it. Note that the dependency on 674647 is a hard one. We cannot check this in while some build bots are running with 10.5 with no 10.6 SDK.
Comment 16 Chris Cooper [:coop] 2011-11-02 08:04:58 PDT
(In reply to Ted Mielczarek [:ted, :luser] from comment #11)
> Are we planning on moving our builds to a newer version of XCode? If not,
> why is this necessary? I don't see the problem with continuing to use the
> 10.5 SDK for our 10.5 builds until such point as we need to move to building
> on Lion.

We're actually coming up to a point where this may be necessary. 

Early in 2012, we'll be moving out of one of our current colos (sjc1) where our current Mac build machines (a mixture of old minis and xserves) reside. The new colo (scl3) will not support the old minis due to the cold aisle technology in use. The xserves could be moved, but on their own, they would not provide sufficient build capacity, and many of the xserves have already started to fail since they are reaching the end of their natural lifetime.

We're faced with buying new hardware to replace these builders, and new hardware in this case means minis running 10.7. Sometime in the very near future (January) we'll need to be able to build on Lion for whatever OS targets we still consider relevant. If we can still support 10.5 with only the 10.6 SDK, that would be ideal.

Has there been discussion anywhere about when we would stop officially supporting 10.5 altogether?
Comment 17 Steven Michaud [:smichaud] (Retired) 2011-11-02 08:37:41 PDT
> Has there been discussion anywhere about when we would stop
> officially supporting 10.5 altogether?

I'm not aware of any public discussion.

JP, I remember discussing with you the possibility coordinating the
dropping of support for OS X 10.5 with other changes, including
dropping support for older OS versions on other platforms.  But I
can't find any record of it -- I think we must have been talking on
Skype.  Have these discussions gone any	further?  Are they now public?

Josh, do you know anything about this?
Comment 18 Steven Michaud [:smichaud] (Retired) 2011-11-02 09:07:47 PDT
Chris, do you know anything about what's discussed in comment #17?
Comment 19 JP Rosevear [:jpr] 2011-11-03 10:35:00 PDT
(In reply to Steven Michaud from comment #17)
> > Has there been discussion anywhere about when we would stop
> > officially supporting 10.5 altogether?
> 
> I'm not aware of any public discussion.
> 
> JP, I remember discussing with you the possibility coordinating the
> dropping of support for OS X 10.5 with other changes, including
> dropping support for older OS versions on other platforms.  But I
> can't find any record of it -- I think we must have been talking on
> Skype.  Have these discussions gone any	further?  Are they now public?

The discussions have not happened.  XP prior to SP2 and Windows ME I believe are also candidates for dropping soon.
Comment 20 Dustin J. Mitchell [:dustin] 2012-01-04 11:58:10 PST
We are coming to a decision point with respect to the datacenter move -- we will bear significant expense to move ancient hardware to a new datacenter if we don't have (or know we will have soon) the capability to build for 10.5 on 10.7 by the end of January.  The expense is the worse because it's good money after bad -- these ancient minis will die eventually, hopefully after we stop needing them.

Is it possible to finish this bug in the next 3.5 weeks?
Comment 21 Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2012-01-04 14:20:07 PST
hopefully you mean 10.6, right?

It should now be possible to build to 10.5 from 10.6 (module releng work), but I have not tested 10.7 -> 10.5 in a long time and it requires using the 10.6 sdk, which should work, but requires more testing.
Comment 22 Steven Michaud [:smichaud] (Retired) 2012-01-04 14:33:24 PST
Let me remind everyone that we need user testing on OS X 10.5 of builds that have been made with the 10.6 SDK.

I suggest we start very soon to build trunk nightlies (the 32-bit parts of them) using the 10.6 SDK.  This won't give us a whole lot of testing, but at least it will be a start.
Comment 23 Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2012-01-04 14:37:23 PST
I think it is easier to switch the build to the 10.6 machines first (but still using  the 10.5 sdk) and then switch the SDK, but I will let someone from releng confirm.
Comment 24 Dustin J. Mitchell [:dustin] 2012-01-04 15:58:46 PST
I actually do mean 10.7.  Specifically, I would like to do *all* mac builds (debug, opt, 32, 64 .. ALL) on 10.7 systems, as we can no longer purchase systems that will run 10.6 or 10.5, and we are losing the ability to house our older Apple hardware (which is slowly dying anyway) as coop described in comment 16.  This isn't quite a sky-is-falling moment: as I mentioned in comment 20, we have a contingency plan, but it's expensive and wasteful and only buys us time on the build-on-10.7 project.

From my understanding, this bug is specifically about teaching the build system to target 10.5 using the 10.6 SDK.  That is a component of building on 10.7, but building on 10.7 also requires building with a version of XCode that is compatible with 10.7.  AIUI that means 4.1, as opposed to the XCode 3 that's available on current 10.6 builders.

Should I open a new bug for the second part?

Is this at all practical in this timescale?

(P.S. the silver lining is that this applies only to build systems - we will have 10.5, 10.6, and 10.7 testers for quite a while, as they are in another datacenter).
Comment 25 Dustin J. Mitchell [:dustin] 2012-01-04 17:13:08 PST
> Should I open a new bug for the second part?

I went with "yes": bug 715397
Comment 26 Armen Zambrano [:armenzg] (EDT/UTC-4) 2012-01-11 14:30:06 PST
On bug 698827 we're working on the last steps to run the 10.5 leak builds on the 10.6 machines.
Comment 27 Armen Zambrano [:armenzg] (EDT/UTC-4) 2012-01-19 10:58:30 PST
After bug 674647 got fixed we only need darwin9 slaves for:
* mozilla-aurora
* mozilla-beta
* mozilla-release
* mozilla-1.9.2 (aka Firefox 3.6 which is to be EOL on Apr. 24th)

We're going to backport that work to mozilla-aurora on bug 674647
Comment 28 Armen Zambrano [:armenzg] (EDT/UTC-4) 2012-01-19 12:30:49 PST
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #27)
> We're going to backport that work to mozilla-aurora on bug 674647

That is bug 719499
Comment 29 Mike Taylor [:bear] 2012-05-15 07:05:17 PDT
should have removed the blocker bug # also - this no longer blocks scl3
Comment 30 Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2012-08-08 07:22:16 PDT
This has been fixed some time ago, but I forgot to close the bug.

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