link -NOLOGO -OUT:firefox.exe -PDB:firefox.pdb -ENTRY:wmainCRTStartup -SUBSYSTEM:WINDOWS,5.01 -DYNAMICBASE -DEBUG -DEBUGTYPE:CV -DEBUG -OPT:REF /HEAP:0x40000 -DELAYLOAD:mozglue.dll @C:\build\msys\s\central\obj\clang\browser\app\tmpt2ol0k.list module.res ../../xpcom/glue/standalone/staticruntime/xpcomglue_staticruntime.lib ../../mozglue/build/mozglue.lib kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib secur32.lib netapi32.lib delayimp.lib 0:19.81 C:\build\msys\s\central\obj\clang\browser\app\tmpt2ol0k.list: 0:19.81 nsBrowserApp.obj 0:19.81 ..\..\memory\fallible\fallible.obj 0:19.81 0:19.81 msvcrt.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in libcmt.lib(typinfo.obj) 0:19.81 0:19.81 msvcrt.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in libcmt.lib(typinfo.obj) 0:19.81 0:19.81 LINK : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library 0:19.81 0:19.81 firefox.exe : fatal error LNK1169: one or more multiply defined symbols found We shouldn't combining both msvcrt.lib (DLL CRT) and libcmt.lib (static-linked CRT). I believe this is due to fallible.obj which specifies "/DEFAULTLIB:msvcrt.lib" on clang. On VS we suppress the DEFAULTLIB using the -Zl flag . Apparently this is unsupported according to clang's CLCompatOptions.td . I wonder how hard it would be to support this in clang? I guess the quick and dirty solution would be to just force fallible.cpp to use VS.  https://dxr.mozilla.org/mozilla-central/source/memory/fallible/moz.build#25  http://llvm.org/svn/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td
For completeness I'll acknowledge that the linker itself suggests another possible workaround: 0:19.81 LINK : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library But this issue occurs in other places too (webapprt, maybe more) so I'd rather fix fallible.obj than the individual exes.
Implementing -Zl is probably the right thing to do here... I filed https://llvm.org/bugs/show_bug.cgi?id=24236, and asked for feedback from some of the clang-cl folks to make sure that this makes sense. If they agree, I can implement it.
Summary: clang-cl error LNK4098 due to lack of -Zl support → clang-cl error LNK1169 due to lack of -Zl support
David, do you mind retrying with clang-cl ToT please?
That was fast, thanks! I've confirmed that clang-cl ToT with -Zl does not put defaultlibs into our fallible.obj. I haven't yet run a full build to see if it resolves the linker issue, but I don't expect any problems. One potential issue: clang-cl doesn't forward the -Zl flag if we fall back to cl.exe.
(In reply to David Major [:dmajor] from comment #5) > One potential issue: clang-cl doesn't forward the -Zl flag if we fall back > to cl.exe. Filed as https://llvm.org/bugs/show_bug.cgi?id=24281.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.