magreenblatt
commented
5 months ago Distribution builds using cef_sandbox built with VS 17.9.2 are failing:
3>cef_sandbox.lib(scoped_blocking_call_internal.obj) : error LNK2019: unresolved external symbol "void __cdecl std::_Literal_zero_is_expected(void)" (?_Literal_zero_is_expected@std@@YAXXZ) referenced in function "public: __cdecl std::_Literal_zero::_Literal_zero<int,0>(int)" (??$?0H$0A@@_Literal_zero@std@@QEAA@H@Z)
3>cef_sandbox.lib(waitable_event.obj) : error LNK2001: unresolved external symbol "void __cdecl std::_Literal_zero_is_expected(void)" (?_Literal_zero_is_expected@std@@YAXXZ)
3>C:\Users\Marshall\Downloads\cef_binary_126.1.0+g20a659f+chromium-126.0.6478.26_windows64_beta\build\tests\cefsimple\Debug\cefsimple.exe : fatal error LNK1120: 1 unresolved externalsThis appears to be a bug in either clang or MSVC STL, triggered by base::TimeDelta comparison operator usage (example).
It's not a precompiled routine, it's a deliberately undefined routine which is named to give a hint to what's wrong with the code that does not link. The idea is that the type _Literal_zero has an implicit consteval constructor (see https://en.cppreference.com/w/cpp/language/consteval) which argument may only have the value of 0. Due to consteval the only allowed context is constant expressions, so compilers can throw away the function call when the code is valid
Is your feature request related to a problem? Please describe. Chromium devs build with specific versions of VS, and we should use the same versions when building CEF. For example, Chromium M126 requires toolchain version 14.39.33519 (VS 17.9.2).
Describe the solution you'd like Update master/M126 build requirements to VS 17.9.2. This will fix an issue with Debug builds of the
WinSboxNoFakeGdiInitfeature (remove MSVCP140D.dll dependency on OLE32.DLL).Additional context Chromium tooling should require a specific VS version, see https://crbug.com/343638935. Specific VS version installers can be downloaded here.