1085767 - Migrate Thunderbird to VS 2013

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Standard8, any reason we shouldn't do this ?

Comment 2

[Justin Wood (:Callek)]

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)

Comment 3

[Joshua Cranmer [:jcranmer]]

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

Comment 4

[(Away)]

> It failed in LDAP:
That error was fairly straightforward on the FF side. You'll need some variant of bug 915973.

Comment 5

[(Away)]

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

Comment 6

[Mark Banner (:standard8)]

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.

Comment 7

[Stefan Sitter [:ssitter]]

(In reply to Mark Banner (:standard8) from comment #6)
> Can someone please file a bug for comment 3?

Done. See Bug 1089138.

Comment 8

[Joshua Cranmer [:jcranmer]]

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.

Comment 9

[Takanori MATSUURA]

Any plan for win64 comm-central build to move to VS2013?
It is broken since 25 Nov.

Comment 10

[Joshua Cranmer [:jcranmer]]

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

Comment 11

[(Away)]

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

Comment 12

[(no longer active)]

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?

Comment 13

[Joshua Cranmer [:jcranmer]]

Attachment: Enable MSVC 2013 in the Windows mozconfigs

Comment 14

[Joshua Cranmer [:jcranmer]]

(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 15

[Mike Hommey [:glandium]]

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?

Comment 16

[Joshua Cranmer [:jcranmer]]

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

Comment 17

[Joshua Cranmer [:jcranmer]]

https://hg.mozilla.org/comm-central/rev/036deed5ab5c

Comment 18

[Takanori MATSUURA]

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

Comment 19

[Masatoshi Kimura [:emk]]

Please file a new bug for Tb Win64 builds.

Comment 20

[Takanori MATSUURA]

(In reply to Masatoshi Kimura [:emk] from comment #19)
> Please file a new bug for Tb Win64 builds.

File as bug 1113042.