Duplicate headless::switches errors with jumbo and link.exe |
||
Issue description
When building chrome with these settings I hit multiple duplicate symbol errors. The full error messages are attached. This bug is for one of the issues.
use_lld = false
is_component_build = false
is_debug = false
target_cpu = "x86"
enable_nacl = false
symbol_level = 2
use_jumbo_build = true
The other errors are entirely related to jumbo builds. app/headless_shell_switches.cc is listed in jumbo_component("headless") and also in static_library("headless_shell_browser_lib") and this leads to failures with link.exe. It may be that link.exe has also exposed these bugs.
Can you look at this and figure out what is going on? Is this new, or just exposed by link.exe (probably the latter)?
,
Jan 7
Just from the error message it sounds like code that might have been wrong for a while but relied on the "unused obj file removal" in a linking phase so that the extra switches were remove before the final linking. If that is the problem, you normally just remove files from the sources list and stop compiling them, but headless' build system is a bit complicated and maybe they are not always unused.
,
Jan 7
I think that the source file is needed in two different contexts, so removing it from either one will cause a link failure. Excluding the source file from jumbo builds will reliably avoid the problem because at most one of the .obj files will be pulled in. That's not a completely satisfactory solution however. Ideally we would only have one copy of the .obj file, whereas currently I think we have one in a .lib and one in a source-set. The one in the .lib file is completely ignored in non-jumbo builds (link.exe or lld-link.exe), but in jumbo builds it gets pulled in and link.exe complains. The problem has been hidden before because lld-link is very permissive about this issue. That's unfortunate because it means we don't catch these issues when they initially happen. It would be reasonable to assign this to the person who added the source file twice - arguably jumbo is just revealing the logical issue.
,
Jan 11
Do you happen to have the exact error?
,
Jan 12
Thanks!
,
Jan 13
Are you sure this one only happens with link.exe? If so, this is at least a different issue than https://llvm.org/PR40094.
,
Jan 14
I just tested and confirmed that it *is* specific to link.exe. That is, I used the gn args in comment#0 while synced to 2a10c71087bc0687d2aa4d0bb3416cd5bb51986d to reproduce the link errors. Then I commented out "use_lld = false" and was able to build without warnings or errors. I then tested with the comment#0 settings plus use_goma = true, for faster testing. The errors still repro, with link.exe but not with lld-link. So, unless the grouping of files is changed when building with lld-link versus link.exe this does appear to be an error that lld-link doesn't detect, whether the same error or a different one I don't know. |
||
►
Sign in to add a comment |
||
Comment 1 by brucedaw...@chromium.org
, Jan 5