User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.18) Gecko/20081031 SeaMonkey/1.1.13 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.18) Gecko/20081031 SeaMonkey/1.1.13 64-bit Windows distribution is not (yet) available for end-user and it is not trivial task to build sea monkey from the source for typical user. Reproducible: Always Steps to Reproduce: No 64-bit distribution is available on site.

The Gecko backend code is not yet 100% 64bit safe. KaiRo: I think that this is a WONTFIX for the time being?

Let's keep it around as a reminder for the future, but in the right component, and targeted future. Win32 builds work fine on 64bit Windows, and we know of nothing that would work better with a version compiled for 64bit specifically, so there's no immediate need to do that now. The real need might arise some time in the future, though.

Yes. And Hendikins has been producing 64bit linux builds as well. The main sticking point appears to be OSX where the 64bit APIs are significantly different.

All 64-bit OSes I know of are capable of running 32 bit and 64 bit programs side-by-side, including Linux, Windows, and OS X. There are still people that would like native 64-bit builds for whatever reason. Those work fine on Linux at the moment (although there are no official Firefox builds), but don't work at all on Windows or OS X without patches. Josh is working on OS X, and Makoto Kato is working on Windows.

Only one addition: For Linux users, it's a real pain to get plugins to work when there is 32/64Bit mismatches. For example, I had to fiddle around an hour now with my Suse 11.1 install: Since I need Java6 64Bit (I'm a Java programmer), I had to additionally install Java5 32 Bit (or rather, downgrade to Java5 32Bit) from SuSE YAST, because that is the only easy option to have the two in parallel...

Do not forget that there is no Win64 flash player And as i understand it 64bit programs cannot use any 32bit components. Since the web is becoming heavily flash dependent, not to mention other plugins a 64bit build at this time is not even practical, as Flash and other plugins start shipping win64 versions this will become more of a priority to ship a native 64bit version for windows and other platforms.

(In reply to comment #7) > Do not forget that there is no Win64 flash player And as i understand it 64bit > programs cannot use any 32bit components. > > Since the web is becoming heavily flash dependent, not to mention other plugins > a 64bit build at this time is not even practical, as Flash and other plugins > start shipping win64 versions this will become more of a priority to ship a > native 64bit version for windows and other platforms. Don't forget that there are users who don't care about Flash and don't even use it on their 32bit browser.

(In reply to comment #7) > Do not forget that there is no Win64 flash player And as i understand it 64bit > programs cannot use any 32bit components. > > Since the web is becoming heavily flash dependent, not to mention other plugins > a 64bit build at this time is not even practical, as Flash and other plugins > start shipping win64 versions this will become more of a priority to ship a > native 64bit version for windows and other platforms. the recent work in OOPP(out of process plugin) would make it very possible to run 32bit plug-in in x64 Firefox. so we wouldn't have wait for flash, sliverlight etc.... to catch up

Change components to general because I already have landed build config for x64 to comm-central by another bugs.

Sorry, if General is the right permanent component for any bug, we've got a bug in our component hierarchy. This bug is about enabling a specific build configuration, so Build Config is the right component for it.

[sg:want] because ASLR is more consistently enabled and has a larger address space to work with in 64-bit processes.

I think this is currently dependent on Bug 572395.

Besides getting MozCo to allow for a build slave to do this and the fact Firefox still refuses to do Win64 builds. Mozilla's backend code has well matured into supporting 64bit on Windows as evidenced by the Pale Moon Project as well as the Thunderbird optimized build by Moonchild called FossaMail. I have also from time to time built SeaMonkey targeting Win64. So here is a question. Why are we still not doing this?

64-bit Firefox builds have been available since Firefox 43: https://blog.mozilla.org/futurereleases/2015/12/15/firefox-64-bit-for-windows-available/ https://www.mozilla.org/firefox/all/

Not fixed for Seamonkey.

Additional note. 64 bit suite build configs are now in comm-central. Doing 64 bit builds will be the next task after the 32 bit ones are produced again. Hopefully soon now. FRG

From cursory glance, the items needed are: 1) Build config changes, which m_kato has provided a WIP [if it is still applicable] 2) buildbot changes

While this enables builders, we don't have any slaves that work so this is also blocked on the get-the-win2008r2-slaves up bug. This patch is just to show the win64 builders on the builders list.

Comment on attachment 8824851 [details] [diff] [review] [mozconfigs] Remove invalid lines for win64 mozconfigs. rs=me a=me

https://hg.mozilla.org/comm-central/rev/451f4e89b9f5f99a63a96ab742af78886b7c35a4 Bug 482143 - Remove invalid lines from win64 mozconfigs. r+a=RattyAway

Comment on attachment 8824898 [details] [diff] [review] [config] changes to add win64 builders. > +++ b/seamonkey/config.py > + 'win64': { > + 'base_name': 'WINNT 6.1 %(branch)s', Should probably be > 'base_name': 'WINNT 6.1 x86-64 %(branch)s', > + 'stage_platform': 'win32', win64 I think > + 'build_space': 9, Too low? Fx is 14 > + 'PATH': "${MOZILLABUILD}nsis-2.46u Dead 3.0 now. Still needed? > + 'win64-debug': { > + 'base_name': 'WINNT 6.2 %(branch)s leak test', should be: > 'base_name': 'WINNT 6.1 x86-64 %(branch)s leak test', > + 'build_space': 8, Too low? 9 for Fx > + 'PATH': "${MOZILLABUILD}nsis-2.46u Dead 3.0 now. Still needed? Otherwise great so r+ with NITs fixed and questions answered.

(In reply to Frank-Rainer Grahl (:frg) from comment #23) > Comment on attachment 8824898 [details] [diff] [review] > [config] changes to add win64 builders. > > > +++ b/seamonkey/config.py > > > + 'win64': { > > > + 'base_name': 'WINNT 6.1 %(branch)s', > Should probably be > > 'base_name': 'WINNT 6.1 x86-64 %(branch)s', > > > + 'stage_platform': 'win32', > win64 I think > > > + 'build_space': 9, > Too low? Fx is 14 Will change it to 14. > > > + 'PATH': "${MOZILLABUILD}nsis-2.46u > Dead 3.0 now. Still needed? This is based on what we have on the loaner > > > + 'build_space': 8, > Too low? 9 for Fx Will change it to 9. > > > + 'PATH': "${MOZILLABUILD}nsis-2.46u > Dead 3.0 now. Still needed? > Not sure, tbh. I'll change it to 3.0b1.

Since these are contributed builds, not enabling the unittests.

https://hg.mozilla.org/build/buildbot-configs/rev/fe884f857818aa2d8deb0fffbe6a1104f9264041 Bug 482143 - Enable win64 builders on buildbot. (buildbot-config changes) r=frg

So, how close is this to fruition? What are the roadblocks to closing this one out? Should the "helpwanted" key word be put in? Thanks.

(In reply to Worcester12345 from comment #28) > So, how close is this to fruition? What are the roadblocks to closing this > one out? > > Should the "helpwanted" key word be put in? > > Thanks. Unfortunately, not very close. tl;dr The problem with the Win64(and in general, the Windows platform) is that we do not have any updated Windows systems (2008R2+) that can build SeaMonkey. We have 7 Win2003 systems. Why don't we upgrade those to something newer? There is little point because by the end of the year, they too (along with the rest of our infra) will be decommissioned. Why? Mozilla is moving out of the SCL3 data centre and our infra isn't going along with the move. We have managed to borrow a loaner from Moco to do this but it isn't attached/connected to our build infra in any way. This means that if we need to run triggered builds, I need to log on and trigger the build. So at this point, I have scheduled nightly builds for Win32 and Win64 on this system. There are no debug builds, nor triggered builds or even tests. There is absolutely no way I can sanely sit in front of the loaner to do all that and still be able to fix other stuff. The Release stuff is also done on the loaner so when the release is being done, none of the nightlies are run. That said, I am in the process of setting up a new infra so that I don't need to manually trigger things. Thanks for your patience.

One would think in this world of virtual machines, this could be done on any number of hosts. Heck, there could even be individual VM's for each type of build you describe, at NO ADDITIONAL COST. I'm not understanding the why on this, unless there is some hidden agenda at play here.

Worchester12345, lets just assume that the world is more complicated than you think it is and the remaining devs have a personal life too. We are working on it. If you need an x64 build you can use Bills contributed build at https://www.wg9s.com/comm-esr/ Unless you have something to contribute please abide from just asking when it will be ready and leave the conspiracy theories at the front door too.

So, these are all done on individual pieces of hardware, and not in a VM environment? I cannot imagine as big an outfit as "Mozilla" not having such resources available. I could assist with this if you would like.