Closed Bug 519060 (support-10.6_x64) Opened 15 years ago Closed 14 years ago

[Tracking bug] officially support Mac OSX 10.6 64-bit builds

Categories

(Release Engineering :: General, defect, P4)

x86_64
macOS

Tracking

(blocking2.0 betaN+)

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: jaas, Unassigned)

References

()

Details

(Whiteboard: [10.6])

Attachments

(1 obsolete file)

We're close to being able to build 64-bit Mac OS X builds without patches on trunk. We'd like to have a build tinderbox set up in the ports collection for when that happens.

The tinderbox will need to be a Mac OS X 10.6.1 machine and it would be nice if it produced nightly builds.

The machine can use the same mozconfig as an optimized non-universal 32-bit Intel build.
The patch for bug 513747 will land today or tomorrow, we are ready for a 64-bit Mac OS X tinderbox. A tinderbox will allow us to notice as soon as someone breaks 64-bit Mac OS X builds. I'd also like to have nightly builds from the box available on the FTP server (as a port).
Severity: normal → major
Assignee: build → nobody
Component: Tinderbox Platforms → Release Engineering
QA Contact: dbaron → release
Taking for now, need to sort out priority on this.
Assignee: nobody → joduinn
(In reply to comment #2)
> Taking for now, need to sort out priority on this.
Per discussion with shaver, moving this to Future until we get linux64 and win7 systems into production first. 

Meanwhile:
1) We have separate bugs to track setting up *testing* 32bit builds on 64bit OSX10.6. However, this bug seems to be about creating 64bit builds, so not a DUP. It is not, afaict, possible to generate 64bitIntel+32bitIntel+PPC builds. Do you want us to generate native 64bit builds in addition to the current 32bitIntel+PPC builds? Or should we wait until we drop PPC and produce 64bitIntel+32bitIntel builds? 

2) Terminology: There's no more dedicated tinderbox slaves anymore. Instead we have buildbot slaves in pool. Also, what OS we build on is not necessarily the same as what OS we test on. Tweaking summary to match.
Assignee: joduinn → nobody
Component: Release Engineering → Release Engineering: Future
Summary: set up 64-bit Mac OS X tinderbox → set up 64-bit Mac OSX builds
I am requesting a Mac OS X 10.6 box that will produce optimized 64-bit builds only for now. Not a universal binary. And the same box can run all tests, turnover time isn't that important.

Are you saying this isn't possible any more? No tinderbox until it can be integrated into the pool?
The last patch for 64-bit builds has landed, we can now produce them without patches on trunk. Would be nice to have a tbox so that we can prevent bustage.
Could we produce these on 10.5 machines? Seems like that'd be a lot easier to setup, since that's what all our build slaves are already.
We can build on 10.5. This mozconfig will do it, the resulting build will run on 10.5 and 10.6.
I don't think we need this line from the mozconfig any more:

ac_add_options --disable-crashreporter
(In reply to comment #4)
> I am requesting a Mac OS X 10.6 box that will produce optimized 64-bit builds
> only for now.

Yes, this would be nice. I build all my 64bit builds on 10.6 and so a 10.6box would be very helpfull. And on 10.6 we don't need "-arch", the CROSS_COMPILE part and "--target" in the mozconfig, because 64bit is the default.
What about LLVM or GCD (Grand Central Dispatch) optimized 64-bit builds?
(In reply to comment #4)
> I am requesting a Mac OS X 10.6 box

I don't care any more whether or not the box is a 10.6 box, I tested builds produced on 10.5 and at least for now a 10.5 cross-compiling machine will do just fine.
(In reply to comment #10)
> What about LLVM or GCD (Grand Central Dispatch) optimized 64-bit builds?

This is an IT bug about setting up a tinderbox, not how we actually optimize builds. Lets not get into that stuff here.
blocking2.0: --- → beta1
Another advantage to having 64-bit tbox builds/tests would be that we can test different plugin event/drawing modes. We have to pick one mode combo per architecture to test by default, and we can pick 2 if we have 2 architectures. This doesn't directly have to do with 64-bit but is a nice perk.

I think we test Carbon/CG by default in 32-bit, we can test Cocoa/CG plugins on 64-bit tinderboxes.
josh and I talked about this on phone yesterday, and irc today. 

Summary: best to produce 10.6 64bit on 10.6 machine. For now, we'll not do universal binaries, (10.6 64bit + 10.5 32bit), as the 10.5 SDKs have not been tested and there might also be some makefile work.

Josh putting together list of what needs to be installed.
Assignee: nobody → joduinn
Component: Release Engineering: Future → Release Engineering
Summary: set up 64-bit Mac OSX builds → [Tracking bug] officially support Mac OSX 10.6 64-bit builds
Comment on attachment 417925 [details]
64-bit opt mozconfig for building on 10.5

Per irc with josh, we are not going to do 64bit builds on 10.5. Instead we will use 10.6 machines to produce 64bit builds.
Attachment #417925 - Attachment is obsolete: true
Whiteboard: [10.6]
Depends on: 550335
Depends on: 550886
No longer depends on: 532560
Alias: support-10.6_x64
pushing over to bear, as he's started working on this now.
Assignee: joduinn → bear
From To keep everyone in the loop on new 10.6 x86_64 *and* i386 build work:
....
On 3/18/10 3:28 PM, Josh Aas wrote:
> > I think we're all set for i386/x86_64 universal binaries. Here is my basic mozconfig:
> > 
> > =============================
> > . $topsrcdir/build/macosx/universal/mozconfig-64
> > mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir
> > ac_add_options --enable-application=browser
> > ac_add_options --disable-crashreporter
> > =============================
> > 
> > As you can see, we've added a universal mozconfig file specifically for the i386/x86_64 combination called "mozconfig-64".
> > 
> > You'll need to disable crashreporter on our 64-bit builders for now. We don't have an x86_64 crashreporter for Mac OS X yet.
> > 
> > Is there anything else stopping us from bringing these machines up?

Just me getting this config into a test environment to verify the image
is accurate and then the usual procedures about inserting a new build
slave into the flow.  The sticking point that is currently being worked
on is going thru the OS X work flow and making sure there is the proper
i386/x86_64 separations.

I'll do some manual builds this afternoon and post links so we can
sanity check them.


- -- 
bear (aka Mike Taylor)
Depends on: 411588
No longer depends on: 411588
Removed bug 411588 from the dependency list as universal builds were a scope creep that is not in line with original requirement of 64bit builds.
64-bit only builds are fine with me, whatever gets us up and running faster :)
Depends on: 555335
Depends on: 556118
Depends on: 556125
I don't want sendchanges for these new builds to get generated for talos until bug 557382 is resolved - it shouldn't block the production of the builds themselves but I don't want to confuse the graph server with the results quite yet.
from irc, lets start by enabling builds, without doing sendchanges to talos - we need to verify that results for 32bit builds will not mess with results for 64bit builds.
Depends on: 557569
the remaining issue to get nightly (pre) production builds running is to land
the misc.py changes to override the talos sendchanges master list so that the
talos tests are not started until alice is ready for them.

i'm working on config.py and misc.py patches now
Depends on: 557715
Depends on: 558098
Depends on: 558097
Depends on: 558094
bear could you have a look when you can at bug 557918 wrt to 10.6 debug builds?

I compared it with 10.5 and the output looks the same until it reaches:
localhost - - [12/Apr/2010 01:47:46] "GET /bloatcycle.html HTTP/1.1" 200 -
then it just times out.

Not sure why this is failing intermittently and who knows more about that step.
Depends on: 558947
Depends on: 559182
Depends on: 559623
Depends on: 559643
Depends on: 559841
Depends on: 560336
Depends on: 562629
Depends on: 563048
Blocks: 570114
Depends on: 400296
Depends on: 571331
64-bit OSX builds aren't a beta1 blocker, but we need to understand when we'll want to offically supporting them. Moving this to b2+ for now.
blocking2.0: beta1+ → beta2+
Depends on: 575153
Depends on: 578749
No longer depends on: 571331
Depends on: 579180
No longer depends on: 579180
blocking2.0: beta2+ → betaN+
No longer depends on: 580375
Depends on: 570286
No longer depends on: 550335
No longer depends on: 570286
Assignee: bear → nobody
Priority: -- → P4
I believe that these are officially supported at this point, from the releng stand point at least. We have a pool of build machines, a pool of test machines, nightly updates, release builds -- all of which are as supported as any other platform. None of the remaining bugs are 4.0 blockers.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
If this works, why do XulRunner builds fail? (see bug #600435)
Per that bug, XULRunner support is not blocking anything.
(In reply to comment #26)
> If this works, why do XulRunner builds fail? (see bug #600435)

We don't ship nspr-config with Firefox builds, just the NSPR binaries which are used at runtime.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.