Closed Bug 1135583 Opened 8 years ago Closed 8 years ago

Firefox 64-bit fails to link using VS 2015: "fallible.obj : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in nsBrowserApp.obj"

Categories

(Firefox Build System :: General, defect)

x86_64
Windows NT
defect
Not set
normal

Tracking

(firefox41 fixed)

RESOLVED FIXED
mozilla41
Tracking Status
firefox41 --- fixed

People

(Reporter: xavier114fch, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150222030206

Steps to reproduce:

Build 64-bit Firefox from trunk using VS 2015 CTP5. I have applied the patches from Bug 1119072 (Part 7 and the NOT for checkin one) and Bug 1119776 (Part 8) in order to make it compile.


Actual results:

firefox.exe could not be linked and out came this error:

 1:22.35 nsBrowserApp.obj
 1:23.20 nsBrowserApp.cpp
 1:23.21 firefox.exe
 1:23.33 Executing: link -NOLOGO -OUT:firefox.exe -PDB:firefox.pdb -ENTRY:wmainC
RTStartup -SUBSYSTEM:WINDOWS,6.01 -STACK:2097152 -LARGEADDRESSAWARE -NXCOMPAT -D
YNAMICBASE /HEAP:0x40000 -DELAYLOAD:mozglue.dll @h:\mozilla-inbound\obj\browser\
app\tmposlr_y.list module.res ../../xpcom/glue/standalone/staticruntime/xpcomglu
e_staticruntime.lib ../../mozglue/build/mozglue.lib kernel32.lib user32.lib gdi3
2.lib winmm.lib wsock32.lib advapi32.lib secur32.lib netapi32.lib delayimp.lib
 1:23.33 h:\mozilla-inbound\obj\browser\app\tmposlr_y.list:
 1:23.33     nsBrowserApp.obj
 1:23.33     ..\..\memory\fallible\fallible.obj
 1:23.33
 1:23.33 fallible.obj : error LNK2038: mismatch detected for 'RuntimeLibrary': v
alue 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in nsBrowserApp.
obj
 1:23.33
 1:23.33 firefox.exe : fatal error LNK1319: 1 mismatches detected
 1:23.33
 1:23.34 h:/mozilla-inbound/config/rules.mk:658: recipe for target 'firefox.exe'
 failed
 1:23.34 mozmake.EXE[5]: *** [firefox.exe] Error 1319
 1:23.34 h:/mozilla-inbound/config/recurse.mk:74: recipe for target 'browser/app
/target' failed
 1:23.34 mozmake.EXE[4]: *** [browser/app/target] Error 2


Expected results:

It should have built successfully.
Blocks: VC14
Component: Untriaged → Build Config
This looks like a regression in MSVC 2015, which should be reported to Microsoft so that they can fix it.

Specifically, compiling this source:

   struct fallible_t { };
   const fallible_t fallible = {};

doesn't lead to a .obj containing the /FAILIFMISMATCH:RuntimeLibrary=<something> linker flag in VS 2013 and earlier, while, according to your error message, it does with 2015.
Note, this is something we /can/ workaround on our end, but I'd rather not have to.
The VS2013 fallible.obj is small (2K), as you'd expect.

The VS2015 fallible.obj has a ton more stuff (18K). I'm just looking with a hex editor so I don't really understand the content, but I do see lots of "std::" names. I bet one of those is triggering the FAILIFMISMATCH, not the compiler change per se.

Maybe it's related to the attachment 8546588 [details] [diff] [review] in our patch queues?
(In reply to David Major [:dmajor] from comment #3)
> Maybe it's related to the attachment 8546588 [details] [diff] [review] in
> our patch queues?

See comment 1: this happens without including a single header.
OK. I didn't think you had tried it yourself. It sounded like you were guessing based on the bug reporter's data.
Looking back, I didn't, but fallible.cpp only includes fallible.h, which includes nothing else... but we force include mozilla-config.h everywhere... that could be the root cause.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The extra content comes from |#include <string>| in Char16.h. Prior to VS2015, MSVC got to avoid most of this code. If I send VS2015 down the old VS2013 codepath, the pre-processed file becomes much, much smaller. (Though, it doesn't compile, of course)
See Also: → 1119075
Attached patch Define ELFHACK_BUILD (obsolete) — Splinter Review
Glandium told me to try this. It works. I'm not sure if he meant it as a real fix or a local workaround.
Patch applied and I've got this using VS 2015 RC:

 2:41.02 cd builtins; h:/mozilla-build/mozmake/mozmake.EXE libs
 2:41.64 LINK : fatal error LNK1104: cannot open file 'mozglue.lib'
 2:41.64 ../../../coreconf/rules.mk:285: recipe for target 'h:/mozilla-inbound/obj/security/nss/lib/ckfw/builtins/nssckbi.dll' failed
 2:41.64 mozmake.EXE[7]: *** [h:/mozilla-inbound/obj/security/nss/lib/ckfw/builtins/nssckbi.dll] Error 1104
 2:41.66 ../../coreconf/rules.mk:77: recipe for target 'libs' failed
 2:41.66 mozmake.EXE[6]: *** [libs] Error 2
 2:41.66 Makefile:468: recipe for target 'libs-nss/lib/ckfw' failed
 2:41.66 mozmake.EXE[5]: *** [libs-nss/lib/ckfw] Error 2
 2:41.66 h:/mozilla-inbound/config/recurse.mk:70: recipe for target 'config/external/nss/target' failed
 2:41.66 mozmake.EXE[4]: *** [config/external/nss/target] Error 2
 2:41.66 h:/mozilla-inbound/config/recurse.mk:32: recipe for target 'compile' failed
 2:41.66 mozmake.EXE[3]: *** [compile] Error 2
 2:41.66 h:/mozilla-inbound/config/rules.mk:538: recipe for target 'default' failed
 2:41.66 mozmake.EXE[2]: *** [default] Error 2
 2:41.66 h:/mozilla-inbound/client.mk:400: recipe for target 'realbuild' failed
 2:41.66 mozmake.EXE[1]: *** [realbuild] Error 2
 2:41.66 client.mk:171: recipe for target 'build' failed
 2:41.66 mozmake.EXE: *** [build] Error 2
 2:41.67 0 compiler warnings present.
(In reply to Xavier Fung from comment #9)
> Patch applied and I've got this using VS 2015 RC:
>  2:41.64 LINK : fatal error LNK1104: cannot open file 'mozglue.lib'
Yes, I filed bug 1165442 for that.
Attachment #8606446 - Flags: review?(mh+mozilla)
Comment on attachment 8606446 [details] [diff] [review]
Define ELFHACK_BUILD

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

::: memory/fallible/moz.build
@@ +31,5 @@
> +
> +    if CONFIG['_MSC_VER'] >= '1900':
> +        # This further prevents the CRT name from getting into the .obj file,
> +        # by avoiding pulling in a bunch of string code that uses the CRT.
> +        DEFINES['ELFHACK_BUILD'] = True

ELFHACK_BUILD is, like its name suggests, something indicating that elfhack is being built. Which is obviously not the case here :)
I'd suggest replacing ELFHACK_BUILD with something like DONT_INCLUDE_CHAR16_H. Or, in fact, just defining mozilla_Char16_h (and doing that both here and for elfhack, and remove the ELFHACK_BUILD reference in mozilla-config.h.in.
Attachment #8606446 - Flags: review?(mh+mozilla) → feedback+
Ha - I knew you'd call that out :)
Attachment #8606446 - Attachment is obsolete: true
Attachment #8608716 - Flags: review?(mh+mozilla)
Comment on attachment 8608716 [details] [diff] [review]
Define mozilla_Char16_h

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

::: build/unix/elfhack/inject/moz.build
@@ +17,5 @@
>      "%s.c" % cpu,
>  ]
>  
> +# Prevent Char16.h because this build happens during the export tier
> +DEFINES['mozilla_Char16_h'] = 0

I /think/ a bystander might think 0 would be better replaced with False, which would have the opposite effect as the wanted one. In fact, /I/ wondered that. So I think True would be a better value here and other places.

Now, that comment got me wondering if that was still true... and it sure isn't. In fact elfhack builds fine with Char16.h included. So let's say this: keep your memory/fallible/moz.build change (with True instead of 0), and I'll file a separate bug to remove the ELFHACK_BUILD thing entirely.
Attachment #8608716 - Flags: review?(mh+mozilla) → review+
Even better!
https://hg.mozilla.org/mozilla-central/rev/00c2e00e3c37
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 41
Depends on: 1290645
Component: Build Config → General
Product: Firefox → Firefox Build System
Target Milestone: Firefox 41 → mozilla41
You need to log in before you can comment on or make changes to this bug.