Failed to link obj from cl.exe with lld when is_official_build = true |
|||
Issue descriptionchromium commit: https://chromium.googlesource.com/chromium/src/+/504fd2e8f347bf20638cce9f80ebf065ad017a73 args.gn ``` is_clang = false is_official_build = true use_lld = true ``` PS C:\src\chromium\src> ninja -C .\out\Release\ obj/base/base_static.lib ninja: Entering directory `.\out\Release\' [4/4] LIB obj/base/base_static.lib FAILED: obj/base/base_static.lib C:/src/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False ../../third_party/llvm-build/Release+Asserts/bin/lld-link.exe /lib /llvmlibthin /nologo /ignore:4221 /OUT:obj/base/base_static.lib @obj/base/base_static.lib.rsp obj/base/base_static/base_switches.obj: not a COFF object, bitcode or resource file ..\..\third_party\llvm-build\Release+Asserts\bin\lld-link.exe: error: lib failed ninja: build stopped: subcommand failed.
,
Dec 27 2017
My understanding is that this is a known limitation of lld and is by design, especially when working with non-clang builds. We should probably just add gn asserts to prohibit these illegal combinations. That is: assert(!(use_lld && is_official_build)) assert(!(use_lld && is_win_fastlink)) If the clang/lld team agrees then anybody could add those asserts and any others that seem necessary.
,
Dec 27 2017
The error message seems wrong, because I don't see why cl.exe would be producing a non COFF object file. That part doesn't make sense. My guess is that this has to do with the fact that LTCG is enabled in the object files, but we should be able to detect this and print a more useful error messages like "lld-link cannot link object files created by MSVC with /LTCG". I also don't necessarily see a strict problem with use_lld && is_win_fastlink. A warning maybe, but it won't break anything. lld-link can just map /DEBUG:FASTLINK to /DEBUG:FULL.
,
Dec 27 2017
I agree that LTCG builds are causing IR data to be in the object files which then confuses lld. A better error message would be good but I still think that prohibiting this at the gn level is appropriate. Regarding fastlink I was wondering about that option. Allowing fastlink is handy because it allows faster transitions between link.exe-with-fastlink and lld. Forcing fastlink to be explicitly turned off means that everything needs to be recompiled, because fastlink builds necessarily change a compiler switch. On the other hand, that is also a reason to prohibit use_lld=true with is_win_fastlink=true - the extra debug information overhead that we take on with is_win_fastlink builds is completely unnecessary in lld builds. So, my opinion was that we should explicitly prohibit both combinations using asserts in order to catch the errors as quickly as possible and to save developers from inefficient build settings (fastlink+lld). So, my recommendation would be to add the two asserts and also improve the error message for LTCG .obj files encountered by lld.
,
Apr 3 2018
Should we bother with the gn asserts at this point? It seems academic now that the clang switch has stuck. I filed https://bugs.llvm.org/show_bug.cgi?id=36995 for the LLD error message improvement.
,
Apr 3 2018
Given that we've switched to clang and you've filed a bug for a better lld message I think we can close this one as wontfix.
,
Apr 3 2018
Sounds good. |
|||
►
Sign in to add a comment |
|||
Comment 1 by tikuta@chromium.org
, Dec 25 2017