Closed Bug 926083 Opened 6 years ago Closed 6 years ago

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

Categories

(Firefox Build System :: General, defect, major)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
mozilla27

People

(Reporter: mcsmurf, Assigned: Ehsan)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

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.
I use no .mozconfig file for that build, so standard build options get used.
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).
Duplicate of this bug: 925641
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
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'"
(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
(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.
Is this affecting Metro development?
Flags: needinfo?(mbrubeck)
Flags: needinfo?(ally)
(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)
(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
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 784739
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)
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?).
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
There *is* a real bug here after all.  Let's fix that.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Severity: blocker → major
Attached patch Patch (v1) (obsolete) — Splinter Review
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?
(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+
Attached patch For check-inSplinter Review
Attachment #817292 - Attachment is obsolete: true
Keywords: checkin-needed
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/1b12502d7c23
Status: ASSIGNED → RESOLVED
Closed: 6 years ago6 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.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.