Bug 519060 (support-10.6_x64)

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

RESOLVED FIXED

Status

defect
P4
major
RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: jaas, Unassigned)

Tracking

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [10.6], )

Attachments

(1 obsolete attachment)

Reporter

Description

10 years ago
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.
Reporter

Comment 1

10 years ago
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
Reporter

Comment 4

10 years ago
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?
Reporter

Comment 5

10 years ago
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.
Reporter

Comment 7

10 years ago
We can build on 10.5. This mozconfig will do it, the resulting build will run on 10.5 and 10.6.
Reporter

Comment 8

10 years ago
I don't think we need this line from the mozconfig any more:

ac_add_options --disable-crashreporter

Comment 9

10 years ago
(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.

Comment 10

10 years ago
What about LLVM or GCD (Grand Central Dispatch) optimized 64-bit builds?
Reporter

Comment 11

10 years ago
(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.
Reporter

Comment 12

10 years ago
(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
Reporter

Comment 13

10 years ago
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]

Updated

9 years ago
Depends on: 550335
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)

Updated

9 years ago
Depends on: 411588

Updated

9 years ago
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.
Reporter

Comment 19

9 years ago
64-bit only builds are fine with me, whatever gets us up and running faster :)
Depends on: 555335

Updated

9 years ago
Depends on: 556118

Updated

9 years ago
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

Updated

9 years ago
Depends on: 558098

Updated

9 years ago
Depends on: 558097

Updated

9 years ago
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: 562629

Updated

9 years ago
Blocks: 570114

Updated

9 years ago
Depends on: 400296
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
No longer depends on: 571331

Updated

9 years ago
Depends on: 579180

Updated

9 years ago
No longer depends on: 579180
blocking2.0: beta2+ → betaN+
No longer depends on: 580375

Updated

9 years ago
Depends on: 570286

Updated

9 years ago
No longer depends on: 550335

Updated

9 years ago
No longer depends on: 570286

Updated

9 years ago
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
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 26

9 years ago
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.