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

RESOLVED FIXED in mozilla27

Status

Firefox Build System
General
--
major
RESOLVED FIXED
5 years ago
3 months ago

People

(Reporter: mcsmurf, Assigned: Ehsan)

Tracking

({regression})

Trunk
mozilla27
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

5 years ago
I use no .mozconfig file for that build, so standard build options get used.
(Reporter)

Comment 2

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

Updated

5 years ago
Duplicate of this bug: 925641
(Reporter)

Comment 4

5 years ago
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
(Reporter)

Updated

5 years ago
Summary: Firefox trunk fails to link libxul with MSVC 2012 → Firefox trunk fails to link libxul with MSVC 2012 and newer: "error LNK2038 [...] value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'"

Comment 5

5 years ago
(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.
Blocks: 784739

Comment 6

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

5 years ago
Is this affecting Metro development?
Flags: needinfo?(mbrubeck)
Flags: needinfo?(ally)

Comment 8

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

Comment 10

5 years ago
(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.
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.
Flags: needinfo?(ally)
(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.
I believe I backed out the offending changeset from inbound. This bug is now a duplicate of bug 784739.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 784739
(Reporter)

Comment 14

5 years ago
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.
Flags: needinfo?(netzen)
So is this bug still happening on tip? If so let's re-open it first.
Flags: needinfo?(netzen)
(Reporter)

Comment 16

5 years ago
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?).
(Reporter)

Comment 17

5 years ago
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.
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.
err I meant to say multi threaded dll not multi threaded debug
(Assignee)

Comment 20

5 years ago
There *is* a real bug here after all.  Let's fix that.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Updated

5 years ago
Severity: blocker → major
(Assignee)

Comment 21

5 years ago
Created attachment 817292 [details] [diff] [review]
Patch (v1)

Can someone please try this patch with changeset fc9733225130 re-applied locally?  Thanks!
Assignee: nobody → ehsan
Status: REOPENED → ASSIGNED
Attachment #817292 - Flags: review?(jwalden+bmo)
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.
Attachment #817292 - Flags: feedback+
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?
(Assignee)

Comment 25

5 years ago
(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 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. ;)
Attachment #817292 - Flags: review?(jwalden+bmo) → review+
(Assignee)

Comment 27

5 years ago
Created attachment 817409 [details] [diff] [review]
For check-in
Attachment #817292 - Attachment is obsolete: true
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/1b12502d7c23
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
(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?
(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.
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
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.
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.

Updated

3 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.