Bug 558448 (support-win64)

[Tracking bug] officially support Windows 64-bit builds

NEW
Unassigned

Status

Release Engineering
Platform Support
P2
normal
8 years ago
a month ago

People

(Reporter: coop, Unassigned)

Tracking

(Depends on: 6 bugs, Blocks: 2 bugs, {64bit, meta})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [win64])

Comment hidden (empty)

Updated

8 years ago
Blocks: 471090

Updated

8 years ago
No longer blocks: 471090
Depends on: 471090
Depends on: 559365

Comment 1

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

Updated

7 years ago
Depends on: 561435

Updated

7 years ago
No longer depends on: 561435
Looks like we're closer to completion than we thought! Armen's going to be organizing releng efforts here.
Assignee: nobody → armenzg

Updated

7 years ago
Status: NEW → ASSIGNED
OS: Windows 7 → All
Priority: P4 → P2
Summary: [Tracking bug] officially support Win7 64-bit builds → [Tracking bug] officially support Windows 64-bit builds
Whiteboard: [win7] → [win64]

Updated

7 years ago
Depends on: 561846
what about http://www.mozilla-x86-64.com/ ?

Comment 4

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

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

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

Updated

7 years ago
Depends on: 565402

Updated

7 years ago
Depends on: 565970

Updated

7 years ago
Depends on: 565972

Updated

7 years ago
Depends on: 561740

Updated

7 years ago
Priority: P2 → P4

Updated

7 years ago
Depends on: 567154
Depends on: 567167
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?
(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

7 years ago
(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
No longer depends on: 567167
Depends on: 571143

Updated

7 years ago
Alias: support-win64

Updated

7 years ago
Depends on: 575912
Blocks: 561435

Updated

7 years ago
Depends on: 579331
Depends on: 582603

Comment 11

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

Updated

7 years ago
Depends on: 604323

Updated

7 years ago
Depends on: 606473

Updated

7 years ago
No longer depends on: 604323

Updated

7 years ago
Depends on: 575041

Updated

7 years ago
Depends on: 627039

Updated

7 years ago
Depends on: 633047

Updated

7 years ago
Priority: P4 → P5
Blocks: 634233

Updated

7 years ago
Priority: P5 → P3
Whiteboard: [win64] → [win64][q1goal]

Updated

7 years ago
Depends on: 637842
Depends on: 640757

Updated

7 years ago
Depends on: 637973

Updated

7 years ago
Depends on: 641940

Updated

7 years ago
Depends on: 642199

Updated

7 years ago
No longer blocks: 561435
Depends on: 561435

Updated

7 years ago
Depends on: 596337

Updated

7 years ago
Depends on: 647287

Updated

7 years ago
Priority: P3 → P4

Comment 12

6 years ago
Nothing to be done until bug 645024 is fixed.
Priority: P4 → P5
No longer depends on: 637973

Updated

6 years ago
Depends on: 629690

Updated

6 years ago
Depends on: 656175

Updated

6 years ago
Depends on: 669384

Updated

6 years ago
Depends on: 670697

Updated

6 years ago
Depends on: 667024

Updated

6 years ago
No longer depends on: 606473

Updated

6 years ago
No longer depends on: 640757

Updated

6 years ago
Depends on: 670761

Updated

6 years ago
Depends on: 670915

Updated

6 years ago
No longer depends on: 575041

Updated

6 years ago
Depends on: 671000

Updated

6 years ago
Depends on: 671260

Updated

6 years ago
No longer depends on: 633047

Comment 13

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

Updated

6 years ago
Depends on: 663748

Updated

6 years ago
Depends on: 672799

Updated

6 years ago
Depends on: 674045

Updated

6 years ago
Depends on: 677116

Updated

6 years ago
Depends on: 679334

Updated

6 years ago
Depends on: 679473

Updated

6 years ago
Depends on: 679809

Updated

6 years ago
Depends on: 679818

Updated

6 years ago
No longer depends on: 663748

Updated

6 years ago
Depends on: 663748

Updated

6 years ago
No longer depends on: 679334

Updated

6 years ago
Depends on: 671647

Comment 14

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

Updated

6 years ago
Depends on: 675135

Updated

6 years ago
Depends on: 680928

Updated

6 years ago
Depends on: 680818

Updated

6 years ago
No longer depends on: 680928

Comment 15

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

Updated

6 years ago
Depends on: 681238

Updated

6 years ago
Depends on: 683976

Updated

6 years ago
Depends on: 684019

Updated

6 years ago
Depends on: 684768

Updated

6 years ago
Depends on: 685115

Comment 16

6 years ago
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
Depends on: 681158, 685667

Updated

6 years ago
Depends on: 685887

Comment 17

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

Updated

6 years ago
Depends on: 687021
Depends on: 689288
Depends on: 689328

Updated

6 years ago
Depends on: 691467

Updated

6 years ago
Depends on: 692692

Updated

6 years ago
Duplicate of this bug: 696738

Updated

6 years ago
Depends on: 709624
Depends on: 730824
Depends on: 715876
Depends on: 740669

Comment 19

5 years ago
Can that [q1goal] in the whiteboard please be moved/changed?
Whiteboard: [win64][q1goal] → [win64]

Updated

5 years ago
No longer depends on: 684019

Updated

5 years ago
Depends on: 784891

Updated

5 years ago
Depends on: 692715
Depends on: 797208

Updated

5 years ago
Assignee: armenzg → nobody

Updated

5 years ago
Depends on: 814009
Component: Release Engineering → Release Engineering: Platform Support
QA Contact: coop

Updated

4 years ago
Depends on: 880004
(Assignee)

Updated

4 years ago
Product: mozilla.org → Release Engineering

Comment 20

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

4 years ago
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.
Depends on: 953057
(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).

Updated

3 years ago
Depends on: 1007726

Updated

3 years ago
Status: ASSIGNED → NEW

Comment 23

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

Comment 24

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

Comment 25

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

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

Updated

3 years ago
Depends on: 1080083

Comment 27

3 years ago
Can I ask when we are going to start again as getting asked a lot from it
(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

Updated

3 years ago
Depends on: 1121286
Depends on: 1135320
Depends on: 1144361
Depends on: 1180792
Depends on: 1181014
Depends on: 1150083

Updated

2 years ago
Depends on: 1185105

Comment 29

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

Updated

2 years ago
Depends on: 1187005

Updated

2 years ago
Depends on: 1145082
Depends on: 1210535

Updated

2 years ago
Depends on: 1223104

Updated

2 years ago
Depends on: 1115490

Updated

2 years ago
Depends on: 1224298

Updated

2 years ago
No longer depends on: 1224298

Updated

2 years ago
Depends on: 1227211
No longer depends on: 1227211

Updated

2 years ago
Depends on: 1226401
Depends on: 1278315
Depends on: 1274659, 1283274, 1165891
Keywords: 64bit
OS: All → Windows
Priority: P5 → P3
Depends on: 882138
Depends on: 1269807, 1123755
No longer depends on: 1145082, 1274659
Blocks: 1274659
Depends on: 1140411
Depends on: 1299187
Depends on: 1295181
No longer depends on: 1299187
Depends on: 1268470
Depends on: 1229252
Depends on: 597738
No longer depends on: 953057
Depends on: 1240977
Depends on: 1240848
Depends on: 1300083
Depends on: 1263595

Updated

11 months ago
Depends on: 1303361
Depends on: 1304933
No longer depends on: 1295181
Depends on: 1291084
Depends on: 1307997
Depends on: 1308506
Depends on: 1308863
Depends on: 1309847
Depends on: 1310163
Depends on: 1302078
Depends on: 1276558
Depends on: 1314183
No longer depends on: 1229252
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.
Depends on: 1253261, 1284897
No longer depends on: 1123755
No longer depends on: 1165891
Keywords: meta
Priority: P3 → P2
Depends on: 1317281
No longer depends on: 1303361
Depends on: 1318039
Depends on: 1315089

Updated

9 months ago
Depends on: 1320662
Depends on: 1321493
Depends on: 1323325

Updated

8 months ago
Depends on: 1323460
Depends on: 1329328
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?
(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. :)
Depends on: 1331086
Depends on: 1332063
Depends on: 1297247
Depends on: 1317995

Updated

7 months ago
Depends on: 1337499
Depends on: 1338583
Depends on: 1336517
Depends on: 1339870
No longer depends on: 1339870
No longer depends on: 1317995

Updated

4 months ago
Depends on: 1357218

Comment 33

3 months ago
Is there a "tracking bug" for "Seamonkey", similar to this one?
Blocks: 1258224
Depends on: 783578
You need to log in before you can comment on or make changes to this bug.