558448 - (support-win64) [Tracking bug] officially support Windows 64-bit builds

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: CIDuty, task, P2)

Comment 1

[Armen [:armenzg]]

Any work with regards 64 bit windows builds is dependent on actually being able to build it. This bug is blocked on bug 471090 to provide the bits.

We will revisit this work once we see bug 471090 getting close to completion.

Comment 2

[Chris Cooper [:coop] (he/him)]

Looks like we're closer to completion than we thought! Armen's going to be organizing releng efforts here.

Comment 3

[Antoine Turmel [:GeekShadow]]

what about http://www.mozilla-x86-64.com/ ?

Comment 4

[Armen [:armenzg]]

(In reply to comment #3)
> what about http://www.mozilla-x86-64.com/ ?

They won't (whoever is running it) have to worry anymore to generate the 64 bit builds themselves once we have this completed.

Comment 5

[[e-mail] (:bhearsum)]

(In reply to comment #4)
> (In reply to comment #3)
> > what about http://www.mozilla-x86-64.com/ ?
> 
> They won't (whoever is running it) have to worry anymore to generate the 64 bit
> builds themselves once we have this completed.

Not to mention that Mozilla Developers will be working explicitly on making sure Firefox compiled for a 64-bit host passes unit tests, is performant, and provides the same user experience as any other platform we ship.

Comment 6

[Josh Tumath]

I know this isn't the place to ask this, but will plug-ins need to be made 64-bit as well, or will they still work?

Comment 7

[Armen [:armenzg]]

Hey Josh, that will be more under one of the bugs of bug 471090 since it is more of a developers question. This bug tries to track the automation changes required to fully support this type of build.

Developers will probably have to find a way to wrap plugins that are not yet 64 bit enabled.

Comment 8

[Steve Roussey (:sroussey)]

Safari in MacOS Snow Leopard is 64 bit and ships with 'out of process plugins' specifically such that plugin developers did not have to change anything. Surely, that will be the case for Firefox as well. If not, perhaps that should be filed as a new bug?

Comment 9

[Makoto Kato [:m_kato]]

(In reply to comment #8)
> Safari in MacOS Snow Leopard is 64 bit and ships with 'out of process plugins'
> specifically such that plugin developers did not have to change anything.
> Surely, that will be the case for Firefox as well. If not, perhaps that should
> be filed as a new bug?

You should file it as new bug.

Comment 10

[Armen [:armenzg]]

(In reply to comment #9)
> (In reply to comment #8)
> > Safari in MacOS Snow Leopard is 64 bit and ships with 'out of process plugins'
> > specifically such that plugin developers did not have to change anything.
> > Surely, that will be the case for Firefox as well. If not, perhaps that should
> > be filed as a new bug?
> 
> You should file it as new bug.

You can also try asking in:
http://groups.google.com/group/mozilla.dev.platform/topics

Comment 11

[Armen [:armenzg]]

Status update
=============
* I wasn't able to install OPSI after several days trying on the reference machine (see bug 596337)
* After we got OPSI working we would need to install nagios and few easier things
* Right now this work has low priority as it does not block FF4 and there is just so much in my plate that needs to be fixed for FF4
* Before tackling this again I need to setup the Linux64 IX reference machine as it is a FF4 blocking platform

Comment 12

[Armen [:armenzg]]

Nothing to be done until bug 645024 is fixed.

Comment 13

[Armen [:armenzg]]

Asked on dev.planning and dev.tree-management to unhide jobs and suites that are green [1].

#### status
- we have 4 production build machines
- all suites except mochitest-1 are green
- we are only running builds on mozilla-central
- looking to unhide jobs

[1] http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/312a7b697a3e0f30#
[2] http://tbpl.mozilla.org/?tree=Firefox&noignore=1&jobname=WINNT%206.1

Comment 14

[Armen [:armenzg]]

Status update
#############
releng:
* [P1] bug 679809 - add Try support
* [P1] bug 677116 - fix symbols' naming
* [P2] bug 667024 - reimage win7x64 slaves (we don't have capacity)
* [P3] bug 627039 - nagios checks for nightly builds
* [P3] bug 656175 - slavealloc support for win7x64 slaves
* [P3] bug 674045 - add win64 to wait times emails
* [P4] bug 575912 - provide xulrunner
* [P4] bug 672799 - start using VS2010

Build:Config:
* [P1] bug 679473 - compilation error
* [P1] bug 663748 make check failures - turns opt builds to orange
* debug builds:
** [P1] bug 669384 symbols for debug builds
** [P1] bug 670915 - make package fails for debug builds
* [P4] bug 671000 - make buildsymbols take 10x longer than win32

Relops:
* [P1] bug 670761 - clone remaining win64 slaves (almost done)
* [P1] bug 671647 - add nagios checks for win64 slaves
* [P5] bug 679818 - clone a couple more slaves

Comment 15

[Armen [:armenzg]]

This is the list of Build:Config bugs that I want to be fixed so we can get to green:
* [P1] bug 663748 - make check failures - turns opt builds to orange
* [P1] bug 675135 - should use -Fo instead of -o on MASM (LINK : fatal error LNK1181: cannot open input file 'methodjit/TrampolineMasmX64.obj') 
* [P1] bug 680818 - HAVE_STDCALL is unnecessary on Win64

Comment 16

[Armen [:armenzg]]

All the Build:Config issues from comment 15 got fixed as well as bug 679334, bug 675135, bug 680928, bug 680818 and bug 681238 (it took a while to get back to green!).

Other critical releng bugs that got fixed recently to get to green are:
* bug 684768 - win64 machines failing to send sendchanges to talos.m.o
* bug 685115 - we had to disable uploading symbols for try

Other completed bugs:
* [P1] bug 679809 - add Try support
* [P1] bug 677116 - fix symbols' naming
* [P3] bug 656175 - slavealloc support for win7x64 slaves
* [P3] bug 674045 - add win64 to wait times emails
* [P1] bug 670761 - clone remaining win64 slaves
* [P1] bug 671647 - add nagios checks for win64 slaves

Status update
#############
releng:
* [P1] bug 681158 - re-add few branches were we disabled win64
* [P1] bug 685667 - disable unit test and talos for win7 x64 until we have enough capacity
** it needs bug 667024 to be fixed
* [P3] bug 684019 - add few more win64 slaves
* [P4] bug 685115 - try symbols are disabled for win64
* [P4] bug 627039 - nagios checks for nightly builds
* [P4] bug 575912 - provide xulrunner
* [P4] bug 672799 - start using VS2010

Build:Config:
* debug builds:
** [P1] bug 669384 symbols for debug builds
** [P1] bug 670915 - make package fails for debug builds
* [P4] bug 671000 - make buildsymbols take 10x longer than win32

Relops:
* [P1] bug 667024 - setup win7x64 slaves
** which is blocked on bug 674607
* [P3] bug 683976 - add newer runslave.py and buildbot-0.8.4 to cloning process
* [P5] bug 679818 - clone a couple more slaves

Comment 17

[Armen [:armenzg]]

I have enabled win64 for all remaining branches. I have disabled tests for win7 64-bit everywhere except for mozilla-central until we have enough capacity (bug 667024).

Done bugs:
* [P1] bug 681158 - re-add few branches were we disabled win64
* [P1] bug 685667 - disable unit test and talos for win7 x64 until we have enough capacity

Status update
#############
releng:
* [P3] [NEW] bug 685887 - Disable symbols for win64 *debug* builds
* [P3] bug 684019 - add few more win64 slaves
* [P4] bug 685115 - try symbols are disabled for win64
* [P4] bug 627039 - nagios checks for nightly builds
* [P4] bug 575912 - provide xulrunner
* [P4] bug 672799 - start using VS2010

Build:Config:
* debug builds:
** [P1] bug 669384 - symbols for debug builds (Microsoft bug)
** [P1] bug 670915 - make package fails for debug builds
* [P4] bug 671000 - make buildsymbols take 10x longer than win32

Relops:
* [P1] bug 667024 - setup win7x64 slaves
** which is blocked on bug 674607 - take a snapshot
* [P3] bug 683976 - add newer runslave.py and buildbot-0.8.4 to cloning process
* [P5] bug 679818 - clone a couple more slaves

Comment 19

[Mardeg]

Can that [q1goal] in the whiteboard please be moved/changed?

Comment 20

[User Dderss]

It looks like bug #953056, bug #953057, bug #953174 all appear only when FF29a1 is run in 64-bit edition. Can anyone look at them, please?

Comment 21

[sjw]

I'm using the 64bit Release build on Linux and the 64bit Nightly build on Windows since years. I never got any 64bit specific errors on Windows. So could someone explain me in simple words why Firefox 64bit is still only available as a Nightly build? And why does it work on Linux?
Today, most new computers are 64bit and other projects like Waterfox already released a stable 64bit version of Gecko-based browsers. So I think this is a quiet important bug to not loose the lead.

Comment 22

[Tony Mechelynck [:tonymec]]

(In reply to sjw from comment #21)
> I'm using the 64bit Release build on Linux and the 64bit Nightly build on
> Windows since years. I never got any 64bit specific errors on Windows. So
> could someone explain me in simple words why Firefox 64bit is still only
> available as a Nightly build? And why does it work on Linux?
> Today, most new computers are 64bit and other projects like Waterfox already
> released a stable 64bit version of Gecko-based browsers. So I think this is
> a quiet important bug to not loose the lead.

The "simple words" are that Windows and Linux are vastly different: the compilers are different and the OS is different, just to name the most obvious. Now Mozilla applications don't run on the bare metal: they have to be compiled to interface with, ultimately, the entry points provided by the OS and its system libraries.

On Windows, the OS provides the WOW64 subsystem which is felt quite adequate for running 32-bit applications on a 64-bit OS. Not so on Linux, where 32-on-64-bit libraries exist, but the system administrator has to install them separately for each installed package, and not every sysadmin does it.

This said (and, developers, sorry for the bugspam) the right place for this kind of support questions is not on Bugzilla but in newsgroups and/or mailing lists such as mozilla.dev.apps.firefox (or whatever it has become, maybe https://mail.mozilla.org/listinfo/firefox-dev ) or forums such as the Mozillazine ones http://forums.mozillazine.org/ (which, notwithstanding the name similarity, are not officially affiliated with Mozilla: they are just kept up as a mutual-help place for Mozilla lovers).

Comment 23

[sjw]

Google released a 64-bit version of Google Chrome today.
[DE] https://www.googlewatchblog.de/2014/06/chrome-64-bit-fuer-windows/

Comment 24

[David Weir (satdav)]

I know from my experience what there's still a demand for windows 64 bit build

Comment 25

[User Dderss]

The decision to drop 64-bit support is a backward, upside-down disaster. I was shocked when I learned about how short-sighted Mozilla management was about it. Now pro users have to use clutches like this https://addons.mozilla.org/en-US/firefox/addon/prevent-out-of-virtual-memo/ to manage FF at bearable usability level. Now even iPhone has 64-bit browser; not having it for Windows is ridiculous. (And no, Nightly build is no way a replacement for properly supported official release; I know because I had my share of glitches no could possibly assigned to fix simply because 64-bit is not officially supported.)

Comment 26

[Florian Bender]

Win64 is going to happen, indeed rather sooner than later (though no definitive time set). Nothing was removed or dropped regarding Win64. Please refrain from adding comments to this (or any other) bug that are not about implementation. If you want to discuss, please go to the user groups.

Comment 27

[David Weir (satdav)]

Can I ask when we are going to start again as getting asked a lot from it

Comment 28

[Ryan VanderMeulen [:RyanVM]]

(In reply to David Weir (satdav) from comment #27)
> Can I ask when we are going to start again as getting asked a lot from it

https://groups.google.com/forum/#!topic/mozilla.dev.platform/7tEPeFU4TMI

Comment 29

[sjw]

Are there any plans for a notification in existing 32-bit Installations on win64 platforms to motivate the users to switch?

Comment 30

[Chris Peterson [:cpeterson]]

NPAPI sandbox meta bug 1123755 no longer needs to block the roll-out of our 64-bit stub installer. Only two of the remaining NPAPI sandbox bugs that are still open (bug 1253261 and bug 1284897) need to block and David Parks is actively working on them.

Comment 31

[Chris Cooper [:coop] (he/him)]

We've officially supported Win64 builds for years now, and this is just becoming a shopping list of random bustages.

What's the proper component for this bug, or does this bug (and likewise bug 471090) even need to exist any longer?

Comment 32

[Chris Peterson [:cpeterson]]

(In reply to Chris Cooper [:coop] from comment #31)
> We've officially supported Win64 builds for years now, and this is just
> becoming a shopping list of random bustages.
> 
> What's the proper component for this bug, or does this bug (and likewise bug
> 471090) even need to exist any longer?

I had planned to resolve this bug as fixed when we ship the new Win64-aware stub installer (bug 797208) in Firefox 53 or 54. I'm currently using this bug to track issues that block the Win64-aware stub installer from riding the train to release, not just any random Win64 issue.

I think bug 471090 is only about some SeaMonkey issues that I'm not monitoring. Feel free to close that bug. :)

Comment 33

[Worcester12345]

Is there a "tracking bug" for "Seamonkey", similar to this one?

Comment 34

[Chris Peterson [:cpeterson]]

I think we can resolve this win64 tracking bug as fixed. 64-bit is the stub installer's default as of Firefox 55 (bug 1340936) and we have begun migrating eligible 32-bit Firefox 56.0 users to 64-bit 56.0.1 (bug 1274659). \o/

(In reply to Worcester12345 from comment #33)
> Is there a "tracking bug" for "Seamonkey", similar to this one?

I think bug 482143 is tracking 64-bit SeaMonkey builds.