926083 - Firefox trunk fails to link libxul with MSVC 2012 and newer: "error LNK2038 [...] value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'"

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Frank Wein [:mcsmurf]]

With current mozilla-central source code I cannot build/link libxul anymore with Visual Studio 2012 on Windows (this used to work):
[...]
136:50.71 uachelper.obj : error LNK2038: Konflikt ermittelt für "RuntimeLibrary": Der Wert "MT_StaticRelease" stimmt nicht mit dem Wert "MD_DynamicRelease" in nsBidiUtils.obj überein.
136:50.71 readstrings.obj : error LNK2038: Konflikt ermittelt für "RuntimeLibrary": Der Wert "MT_StaticRelease" stimmt nicht mit dem Wert "MD_DynamicRelease" in nsBidiUtils.obj überein.
136:50.71 updatelogging.obj : error LNK2038: Konflikt ermittelt für "RuntimeLibrary": Der Wert "MT_StaticRelease" stimmt nicht mit dem Wert "MD_DynamicRelease" in nsBidiUtils.obj überein.
[...]

In English this basically means "mismatch detected for "RuntimeLibrary": Value "MT_StaticRelease" doesn't match value "MD_DynamicRelease" in [object file]"

This probably does not belong in this component, need to see where to move this bug to.

Comment 1

[Frank Wein [:mcsmurf]]

I use no .mozconfig file for that build, so standard build options get used.

Comment 2

[Frank Wein [:mcsmurf]]

I was a bit curious what checkin actually triggered (not caused as far as I know!) this bug here, it's http://hg.mozilla.org/mozilla-central/rev/fc9733225130 from Bug 784739 (tested by spinning a few builds locally).

Comment 4

[Frank Wein [:mcsmurf]]

English error messages from the duped bug:
115:51.26 uachelper.obj : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in nsBidiUtils.obj
115:51.26 readstrings.obj : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in nsBidiUtils.obj
115:51.27 updatelogging.obj : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in nsBidiUtils.obj

Comment 5

[Jim Mathies [:jimm]]

(In reply to Frank Wein [:mcsmurf] from comment #2)
> I was a bit curious what checkin actually triggered (not caused as far as I
> know!) this bug here, it's
> http://hg.mozilla.org/mozilla-central/rev/fc9733225130 from Bug 784739
> (tested by spinning a few builds locally).

confirmed.

Comment 6

[Jim Mathies [:jimm]]

(In reply to Frank Wein [:mcsmurf] from comment #4)
> English error messages from the duped bug:
> 115:51.26 uachelper.obj : error LNK2038: mismatch detected for
> 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value
> 'MD_DynamicRelease' in nsBidiUtils.obj
> 115:51.26 readstrings.obj : error LNK2038: mismatch detected for
> 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value
> 'MD_DynamicRelease' in nsBidiUtils.obj
> 115:51.27 updatelogging.obj : error LNK2038: mismatch detected for
> 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value
> 'MD_DynamicRelease' in nsBidiUtils.obj

What this means is we are trying to link a module that has been compiled against the static runtime libs with a module that was compiled against dynamic runtime libs. With vc11 we can't mix these anymore. I'm having a hard time identifying why the change in fc9733225130 triggered this though.

Comment 7

[Gregory Szorc [:gps]]

Is this affecting Metro development?

Comment 8

[Gregory Szorc [:gps]]

(In reply to Frank Wein [:mcsmurf] from comment #0)
> 136:50.71 uachelper.obj : error LNK2038: Konflikt ermittelt für
> "RuntimeLibrary": Der Wert "MT_StaticRelease" stimmt nicht mit dem Wert
> "MD_DynamicRelease" in nsBidiUtils.obj überein.

136 minutes elapsed build time?! Are you building on a tablet or some other insanely slow machine? Your build times should be no longer than 40 minutes on Windows.

Comment 9

[Matt Brubeck (:mbrubeck)]

(In reply to Gregory Szorc [:gps] from comment #7)
> Is this affecting Metro development?

It's affecting individual developers using VS2012.  We can downgrade to 2010 to work around the problem if necessary, though.

Comment 10

[Frank Wein [:mcsmurf]]

(In reply to Gregory Szorc [:gps] from comment #8)
> (In reply to Frank Wein [:mcsmurf] from comment #0)
> > 136:50.71 uachelper.obj : error LNK2038: Konflikt ermittelt für
> > "RuntimeLibrary": Der Wert "MT_StaticRelease" stimmt nicht mit dem Wert
> > "MD_DynamicRelease" in nsBidiUtils.obj überein.
> 
> 136 minutes elapsed build time?! Are you building on a tablet or some other
> insanely slow machine? Your build times should be no longer than 40 minutes
> on Windows.
:) this is some Win8 Intel i5 notebook with a ultra-low voltage CPU, I only use it occasionally to build things (and do some other work on it while it's building). But also on a normal i5 3,7ghz desktop machine it usually takes me 45-50 minutes to build Firefox as clobber (srcdir on SSD, objdir on HDD). Anyway, that's off-topic here.

Comment 11

[Allison Naaktgeboren :ally]

vs2010 on win8.0 also failed to build today's m-c for me, but with a different set of linker errors, https://pastebin.mozilla.org/3260156.

Comment 12

[(Away)]

(In reply to Jim Mathies [:jimm] from comment #6)
> I'm having a hard time identifying why the change in fc9733225130 triggered this though.

I wonder if adding #include NullPtr.h to readstrings.h played a part. That header pulls in Compiler.h and then cstddef and who knows what else under that. If one of those builtin headers does a #pragma comment lib then it could change the linking situation.

Comment 13

[Gregory Szorc [:gps]]

I believe I backed out the offending changeset from inbound. This bug is now a duplicate of bug 784739.

Comment 14

[Frank Wein [:mcsmurf]]

Brian: This bug here is related to the Windows update service, so maybe you can help (although it has been "fixed" for now by some backout): I guess the USE_STATIC_LIBS directive at http://hg.mozilla.org/mozilla-central/annotate/211337f7fb83/toolkit/mozapps/update/common/Makefile.in is necessary for this code to build on Windows? The problem is with MSVC 2012 this causes problems when linking this code into libxul, see Comment 0 and Comment 4.

Comment 15

[Brian R. Bondy [:bbondy]]

So is this bug still happening on tip? If so let's re-open it first.

Comment 16

[Frank Wein [:mcsmurf]]

No longer happening on tip, but just because some NULL->nullptr change has been backed out (the changeset from Comment 2), so not really what caused this bug as far as I can tell (it just uncovered an existing issue?).

Comment 17

[Frank Wein [:mcsmurf]]

Or maybe the NullPtr.h change is more important than I thought... I'll let other decide that. The USE_STATIC_LIBS thing just looked related to the bug for me.

Comment 18

[Brian R. Bondy [:bbondy]]

updateccommon I believe is used by the updater exe, the maintenance service exe, and xul.dll.  I'm not sure how best to fix it while having nullptr.h included, but I think it's probably best just to leave the files in that lib alone and only make the changes to the other files in the other bug.

The root issue is a mismatch of runtime libraries between multi threaded and multi threaded debug. In VC++ you have to keep those runtime libraries all the same to link them together.

Comment 19

[Brian R. Bondy [:bbondy]]

err I meant to say multi threaded dll not multi threaded debug

Comment 20

[(no longer active)]

There *is* a real bug here after all.  Let's fix that.

Comment 21

[(no longer active)]

Attachment: Patch (v1)

Can someone please try this patch with changeset fc9733225130 re-applied locally?  Thanks!

Comment 22

[(no longer active)]

https://tbpl.mozilla.org/?tree=Try&rev=36af104a5df7

Comment 23

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 817292 [details] [diff] [review]
Patch (v1)

Review of attachment 817292 [details] [diff] [review]:
-----------------------------------------------------------------

This patch fixed the build for me with the offending NULL->nullptr changeset applied.

Comment 24

[(Away)]

Does this just delay the issue? E.g. what happens if later one of those cpp files needs to include Compiler.h for some other reason?

Comment 25

[(no longer active)]

(In reply to comment #24)
> Does this just delay the issue?

Yes.  :-)

> E.g. what happens if later one of those cpp
> files needs to include Compiler.h for some other reason?

Then things will blow up again.  Comment 18 seems to suggest that this fix is enough for now, and if this blows up again in a way that we can't work around in the future, then we need to figure out the proper fix for this...

Comment 26

[Nathan Froyd [:froydnj]]

Comment on attachment 817292 [details] [diff] [review]
Patch (v1)

r=me to get things building again.  Looking at the problematic files, it seems pretty unlikely that they are going to have future issues with Compiler.h.

Also ++ for reducing includes. ;)

Comment 27

[(no longer active)]

Attachment: For check-in

Comment 28

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1b12502d7c23

Comment 29

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/1b12502d7c23

Comment 30

[Bill Gianopoulos [:WG9s]]

(In reply to :Ally Naaktgeboren from comment #11)
> vs2010 on win8.0 also failed to build today's m-c for me, but with a
> different set of linker errors, https://pastebin.mozilla.org/3260156.

Probably a stupid questions, but wanted to make sure you did not do something odd like switch VS versions without doing a clobber?

Comment 31

[Allison Naaktgeboren :ally]

(In reply to Bill Gianopoulos [:WG9s] from comment #30)
> (In reply to :Ally Naaktgeboren from comment #11)
> > vs2010 on win8.0 also failed to build today's m-c for me, but with a
> > different set of linker errors, https://pastebin.mozilla.org/3260156.
> 
> Probably a stupid questions, but wanted to make sure you did not do
> something odd like switch VS versions without doing a clobber?

Not a stupid question. I do clobber when switching vs versions.

Comment 32

[Chris Pearce [:cpearce (Not reading bugmail)]]

We're hitting this error again in current tip (once we fixed the other vs2012 error (bug 928091)):

24:24.53 updatehelper.obj : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in n
sBidiUtils.obj
24:24.53
24:24.53 uachelper.obj : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in nsBi
diUtils.obj
24:24.53
24:24.53 pathhash.obj : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in nsBid
iUtils.obj
24:24.53
24:24.53 readstrings.obj : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in ns
BidiUtils.obj
24:24.53
24:24.53 updatelogging.obj : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in
nsBidiUtils.obj
24:24.53
24:24.53    Creating library xul.lib and object xul.exp

Comment 33

[Brian R. Bondy [:bbondy]]

In general I think you can link /MT and /MD lib and exe files together as long as you use  /NODEFAULTLIB:library similar to this:
http://dxr.mozilla.org/mozilla-central/source/configure.in#l7056

That would get rid of the linker errors, I'm not sure what the mismatch detected comes from off hand or how to suppress it though.

Having USE_STATIC_LIBS seems to be what controls the runtime from config/config.mk.
updater uses /MT (because of USE_STATIC_LIBS=1) because it gets copied / executed around.
xul.dll uses /MD.

We should probably just backout the updater changes and handle that and the general problem caused by the change in a new bug.

Comment 34

[Brian R. Bondy [:bbondy]]

Another option is we could build updatecommon with static runtime and without, it's only a few files anyway. We do this for xpcom glue already: http://dxr.mozilla.org/mozilla-central/source/xpcom/glue/staticruntime
Then with the static variant we'd link it to updater and for the non static version we'd link it to xul.