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).

Taking for now, need to sort out priority on this.

(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.

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.

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.

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.

pushing over to bear, as he's started working on this now.

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)

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 :)

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.

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

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.

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.

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.

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.