Issue metadata
Sign in to add a comment
|
Windows: GN build does not fail on duplicate symbols |
||||||||||||||||||||||
Issue description
Version: Chromium master revision 68623971 (#403382)
OS: Windows 10 64-bit
What steps will reproduce the problem?
(1) Create a dynamic library or exe target that duplicates symbols from a dependency. For example, add "Profile::Profile() {}" to a .cc file in a target that depends on the '//chrome/browser' target.
(2) Attempt to build the above target.
What is the expected output?
The build should fail with a link error like the following:
browser.lib(browser.profile.obj) : error LNK2005: "public: __thiscall Profile::Profile(void)" (??0Profile@@QAE@XZ) already defined in libcef_static.lib(libcef_static.chrome_profile_stub.obj)
What do you see instead?
The build succeeds. The linker appears to always take the symbol listed first in the ninja 'build' list (the symbol from libcef_static.lib is used in the above example and no error is displayed).
Please use labels and text to provide additional information.
The GYP build fails with the above linker error as expected. For developer sanity it would probably be better if the GN build also failed.
,
Jul 13 2016
,
Jul 13 2016
@comment#1: I just discovered the "Edit description" link :)
,
Jul 13 2016
Unfortunately this request is, in general, impossible to guarantee. If an object file is in a .lib file then it will not be looked at unless it is needed. This means that many potentially duplicate symbols are undetectable unless both of the relevant .obj files are pulled in. This is unfortunate, to be sure, because it means that adding a (somewhat unrelated) function call can cause an ODR violation/duplication symbol error. The C++ standard authors acknowledged this in their crafting of the One Definition Rule by not requiring that toolchains give a diagnostic for violations, because violations are often not practical to diagnose. I think that this should be closed as won't-fix, but more discussion is welcome.
,
Jul 13 2016
@comment#4: I'm curious why it errors with GYP but not GN. The profile.cc file is part of 'chrome_browser_profiles_sources' defined in chrome/chrome_browser.gypi. In both GN and GYP this list is added to the 'browser' static_library target, which my shared_library target then links via an intermediary shared_library target. So the dependency chain looks like this:
static_library('chrome') -> static_library('libcef_static') -> shared_library('libcef')
The conflicting "Profile::Profile() {}" symbol is defined in 'libcef_static'.
Given that the library dependency structure is the same for both GN and GYP shouldn't the linker error also be the same?
,
Jul 13 2016
@comment#5: Gah, that should say "which my shared_library target then links via an intermediary /static_library/ target".
,
Jul 13 2016
The linking is in general quite different so it doesn't surprise me that there would be differences here. It seems likely that one could track this down to a good reason this is different, and it doesn't seem like a bug to me.
,
Jul 13 2016
OK, thanks for the explanation. Marking this issue as WontFix :).
,
Jul 13 2016
There are probably a bunch of cases where gn would catch this type of bug and gyp wouldn't - I'm starting to think that linking is a process best described by chaos theory: deterministic, but not particularly predictable. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by marshall@chromium.org
, Jul 13 2016