clang-cl error LNK1169 due to lack of -Zl support

RESOLVED FIXED

Status

()

Core
Build Config
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: dmajor (offline), Unassigned)

Tracking

(Blocks: 1 bug)

42 Branch
Points:
---

Firefox Tracking Flags

(firefox42 affected)

Details

(Reporter)

Description

3 years ago
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 [0]. Apparently this is unsupported according to clang's CLCompatOptions.td [1].

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.

[0] https://dxr.mozilla.org/mozilla-central/source/memory/fallible/moz.build#25
[1] http://llvm.org/svn/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td
(Reporter)

Comment 1

3 years ago
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.

Comment 2

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

Comment 3

3 years ago
oops
Summary: clang-cl error LNK4098 due to lack of -Zl support → clang-cl error LNK1169 due to lack of -Zl support

Comment 4

3 years ago
David, do you mind retrying with clang-cl ToT please?
Flags: needinfo?(dmajor)
(Reporter)

Comment 5

3 years ago
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.
Flags: needinfo?(dmajor)

Comment 6

3 years ago
(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.