WinClang DLL cc build broken due to missing export |
||
Issue descriptionThis CL introduced an exported function that references an unexported function: https://codereview.chromium.org/2636323002 The failure: https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin64%28dll%29/builds/8378/steps/compile/logs/stdio FAILED: cc_unittests.exe cc_unittests.exe.pdb C:/b/depot_tools/python276_bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./cc_unittests.exe /PDB:./cc_unittests.exe.pdb @./cc_unittests.exe.rsp tile_manager_unittest.obj : error LNK2019: unresolved external symbol "public: void __cdecl cc::TileManager::Signals::reset(void)" (?reset@Signals@TileManager@cc@@QEAAXXZ) referenced in function "private: virtual void __cdecl cc::`anonymous namespace'::TileManagerTest_AllWorkFinished_Test::TestBody(void)" (?TestBody@TileManagerTest_AllWorkFinished_Test@?A@cc@@EEAAXXZ) ./cc_unittests.exe : fatal error LNK1120: 1 unresolved externals
,
Jan 19 2017
The quick fix is to add CC_EXPORT to struct Signals, but I thought we added logic to clang to avoid these kinds of problems.
,
Jan 19 2017
Yes, Clang r246338 is supposed to handle this. If ResetSignalsForTesting() is dllimport as seen when compiling tile_manager_unittest.cc, the body should not be getting emitted as it references a non-dllexport function. Maybe there's some flaw in how this is built, maybe it's not marked dllimport..
,
Jan 19 2017
> If ResetSignalsForTesting() is dllimport as seen when compiling tile_manager_unittest.cc, the body should not be getting emitted as it references a non-dllexport function. I mean "non-*dllimport* function".
,
Jan 19 2017
It turns out Clang was just broken here. It should be fixed by r292522. In the meantime, I've uploaded | ||
Comment 1 by h...@chromium.org
, Jan 19 2017Labels: -OS-Mac OS-Windows