Like bug 1009807, but for Thunderbird. There are separate mozconfigs in comm-central/mail/config/mozconfigs/. If there were any buildbot-side changes for Firefox, we may need to port them over to buildbot-configs/mozilla/thunderbird_config.py
Standard8, any reason we shouldn't do this ?
fwiw, (not to answer for mark) mozilla-central is slated to drop all support for VS2010 as of dec 15th, and VS2010 is currently in a tier2 state (meaning there are no firefox jobs that use it, and breakages will be fixed when reported - but we don't backout for it) So I'd say absolutely we should switch, asap. At least from my seat. (the dec 15th date was primarily for SeaMonkey's benefit fwiw)
I pushed the straightforward conversion to try: https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=34f9b7955682 It failed in LDAP: cl -Fowhoami.obj -c -W3 -nologo -GF -Gy -MD -O2 -Zi -UDEBUG -U_DEBUG -UWINNT -DMOZILLA_CLIENT=1 -DNDEBUG=1 -DXP_PC=1 -DWIN32=1 -D_WINDOWS=1 -DWIN95=1 -D_PR_GLOBAL_THREADS_ONLY=1 -D_X86_=1 -DFORCE_PR_LOG -DNEEDPROTOS -DNET_SSL -DNO_LIBLCACHE -DLDAP_REFERRALS -DNS_DOMESTIC -UMOZILLA_CLIENT -Ic:/builds/moz2_slave/tb-try-c-cen-w32-0000000000000/build/objdir-tb/dist/public/ldap -Ic:/builds/moz2_slave/tb-try-c-cen-w32-0000000000000/build/ldap/sdks/c-sdk/ldap/include -Ic:/builds/moz2_slave/tb-try-c-cen-w32-0000000000000/build/objdir-tb/dist/./public c:/builds/moz2_slave/tb-try-c-cen-w32-0000000000000/build/ldap/sdks/c-sdk/ldap/libraries/libldap/whoami.c whoami.c cl : Command line warning D9025 : overriding '/DMOZILLA_CLIENT=1' with '/UMOZILLA_CLIENT' c:/builds/moz2_slave/tb-try-c-cen-w32-0000000000000/build/ldap/sdks/c-sdk/ldap/libraries/libldap/whoami.c : fatal error C1041: cannot open program database 'c:\builds\moz2_slave\tb-try-c-cen-w32-0000000000000\build\objdir-tb\ldap\sdks\c-sdk\ldap\libraries\libldap\vc120.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS
> It failed in LDAP: That error was fairly straightforward on the FF side. You'll need some variant of bug 915973.
The biggest thing to watch out for code-wise will be XP SP2 support, which I assume you want. I managed to get around the FF issues in bug 1023941, and Mark ported some of it in bug 1060890, but you will need some testing and perhaps additional workarounds if you don't meet requirement (3) here: http://dxr.mozilla.org/mozilla-central/source/toolkit/xre/WindowsCrtPatch.h#27-32
Can someone please file a bug for comment 3? (In reply to Nick Thomas [:nthomas] from comment #1) > Standard8, any reason we shouldn't do this ? I think it should be done asap to stay on par with FF, obviously we'll need some fixes first.
(In reply to Mark Banner (:standard8) from comment #6) > Can someone please file a bug for comment 3? Done. See Bug 1089138.
With the newer checkins, I ran a vs2013 build: <https://treeherder.mozilla.org/ui/#/jobs?repo=try-comm-central&revision=9c124145fbdc>. The opt builds seem to work, but we appear to have complete xpcshell test failures on the debug builds.
Any plan for win64 comm-central build to move to VS2013? It is broken since 25 Nov.
(In reply to Joshua Cranmer [:jcranmer] from comment #8) > The opt builds seem to work, but we appear to have complete xpcshell test > failures on the debug builds. After some further investigation, the problem seems to be due to a missing 2013 debug CRT. FF does not appear to have hit this issue, and no one seems to know why.
FF builds don't use the debug CRT. I think because it's non-redistributable (or maybe there are technical reasons too). Glandium might know more. http://dxr.mozilla.org/mozilla-central/search?q=MOZ_NO_DEBUG_RTL&case=true
I would expect comm-central to also pick MOZ_NO_DEBUG_RTL from <http://dxr.mozilla.org/mozilla-central/source/configure.in#7259>. glandium, any idea why that wouldn't work?
Assignee: nobody → Pidgeot18
Status: NEW → ASSIGNED
Attachment #8537290 - Flags: review?(mh+mozilla)
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #12) > I would expect comm-central to also pick MOZ_NO_DEBUG_RTL from > <http://dxr.mozilla.org/mozilla-central/source/configure.in#7259>. > glandium, any idea why that wouldn't work? The problem isn't comm-central, it's the LDAP C-SDK. See bug 1112186 for fixing that.
Comment on attachment 8537290 [details] [diff] [review] Enable MSVC 2013 in the Windows mozconfigs Review of attachment 8537290 [details] [diff] [review]: ----------------------------------------------------------------- ::: mail/config/mozconfigs/win32/debug @@ +15,5 @@ > # Package js shell > export MOZ_PACKAGE_JSSHELL=1 > > if test "$PROCESSOR_ARCHITECTURE" = "AMD64" -o "$PROCESSOR_ARCHITEW6432" = "AMD64"; then > + . $topsrcdir/build/win32/mozconfig.vs2013-win64 Is there a specific reason not to do . $topsrcdir/mozilla/build/win32/mozconfig.vs2013-win64?
Attachment #8537290 - Flags: review?(mh+mozilla) → review+
(In reply to Mike Hommey [:glandium] from comment #15) > Is there a specific reason not to do > . $topsrcdir/mozilla/build/win32/mozconfig.vs2013-win64? I believe these mozconfigs are invoked in such a way that $topsrcdir is sometimes comm-central and sometimes mozilla-central. Admittedly the last time I tried this sort of thing was several months ago, so our various build system rewrites may have moved these to only using one version (hopefully m-c's copy). Hmm... except we probably do use the comm-central version once in client.mk that's pre-client.py checkout of mozilla-central.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Win64 build failed even after d655acbc5efe because build/win64/mozconfig.vs2013 does not exist. https://treeherder.mozilla.org/ui/#/jobs?repo=comm-central&revision=036deed5ab5c https://treeherder.mozilla.org/ui/#/jobs?repo=comm-central&revision=d655acbc5efe
Please file a new bug for Tb Win64 builds.
(In reply to Masatoshi Kimura [:emk] from comment #19) > Please file a new bug for Tb Win64 builds. File as bug 1113042.
You need to log in before you can comment on or make changes to this bug.