Bug 519060 (support-10.6_x64)

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

RESOLVED FIXED

Status

Release Engineering
General
P4
major
RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: Josh Aas, Unassigned)

Tracking

other
x86_64
Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [10.6], URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

8 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

8 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

Updated

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

8 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

8 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

8 years ago
Created attachment 417925 [details]
64-bit opt mozconfig for building on 10.5

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

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

ac_add_options --disable-crashreporter

Comment 9

8 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

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

Comment 11

8 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

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

Updated

7 years ago
blocking2.0: --- → beta1
(Reporter)

Comment 13

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

Updated

7 years ago
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
Depends on: 532560
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
Depends on: 545539
Depends on: 545542
Depends on: 548109
Whiteboard: [10.6]
Depends on: 548025

Updated

7 years ago
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
Depends on: 552924
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

7 years ago
Depends on: 411588

Updated

7 years ago
No longer depends on: 411588

Comment 18

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

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

Updated

7 years ago
Depends on: 555335

Updated

7 years ago
Depends on: 556118

Updated

7 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

Comment 22

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

7 years ago
Depends on: 557715

Updated

7 years ago
Depends on: 558098

Updated

7 years ago
Depends on: 558097

Updated

7 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: 558947
Depends on: 559182
Depends on: 558496
Depends on: 559623
Depends on: 559643
Depends on: 559841

Updated

7 years ago
Depends on: 560336
Depends on: 560777

Updated

7 years ago
Depends on: 562629
Depends on: 563048
Depends on: 567424
Depends on: 568212

Updated

7 years ago
Blocks: 570114

Updated

7 years ago
Depends on: 400296
Depends on: 571331
Depends on: 572125
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+

Updated

7 years ago
Depends on: 575153
Depends on: 578749

Updated

7 years ago
No longer depends on: 571331

Updated

7 years ago
Depends on: 579180

Updated

7 years ago
No longer depends on: 579180
blocking2.0: beta2+ → betaN+
Depends on: 580375
No longer depends on: 580375
Depends on: 583671
Depends on: 590345

Updated

7 years ago
Depends on: 570286

Updated

7 years ago
No longer depends on: 550335

Updated

7 years ago
No longer depends on: 570286

Updated

7 years ago
Assignee: bear → nobody

Updated

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

Comment 26

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

Updated

4 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.