Status

defect
RESOLVED FIXED
5 years ago
Last year

People

(Reporter: nthomas, Assigned: jcranmer)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1964] )

Attachments

(1 attachment)

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
Reporter

Updated

5 years ago
OS: Mac OS X → Windows Server 2008
Standard8, any reason we shouldn't do this ?
Flags: needinfo?(standard8)
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)
Assignee

Comment 3

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

Updated

5 years ago
Blocks: cc-backlog
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.
Flags: needinfo?(standard8)
Depends on: 1089138
(In reply to Mark Banner (:standard8) from comment #6)
> Can someone please file a bug for comment 3?

Done. See Bug 1089138.

Updated

5 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1964]
Assignee

Comment 8

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

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

Comment 10

5 years ago
(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.
Flags: needinfo?(dmajor)
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
Flags: needinfo?(dmajor)

Comment 12

5 years ago
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?
Flags: needinfo?(mh+mozilla)
Assignee

Updated

5 years ago
Depends on: 1112186
Assignee

Comment 13

5 years ago
Assignee: nobody → Pidgeot18
Status: NEW → ASSIGNED
Attachment #8537290 - Flags: review?(mh+mozilla)
Assignee

Comment 14

5 years ago
(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.
Flags: needinfo?(mh+mozilla)
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+
Assignee

Comment 16

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

Comment 17

5 years ago
https://hg.mozilla.org/comm-central/rev/036deed5ab5c
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
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.

Updated

5 years ago
No longer blocks: cc-backlog
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.