# Freeze when linking libcef.dll, branch 3770 on Windows 10x64/vs2017/sdk 10.0.17763.132

Issue #2679 wontfix
Denis Yarkovoy created an issue

The title says it all, tried x64 and x86, with and without jumbo build. In all cases linking doesn’t finish after 10+ hours of wait.

then building with

set GN_ARGUMENTS=--ide=vs2017 --sln=cef --filters=//cef/*

1. This seems like a compiler tooling issue, perhaps related to the Clang/LLVM version bundled by Chromium. Marking this as WontFix since I don't believe there's anything we can do for CEF specifically.

Hi @Marshall Greenblatt , I’m getting the same problem in 3809 as well (although I am able to build using is_component_build, is_official_build flags to be true, they are of not much use to us as it requires major refactoring while using). So I want to ask whether the issue has been opened on chromium? If yes can you please provide issue id ?

Chromium does not support non-component Debug builds (see here) so an issue opened with them would likely be closed as WontFix.

You should use the configuration documented on the AutomatedBuildSetup Wiki page if you want to create a build intended for integration with third-party applications.

Windows: Forbid non-component Debug builds (see issue #2679)

→ <<cset de46befc1821>>

Windows: Forbid non-component Debug builds (see issue #2679)

→ <<cset 052b61ddd909>>

Windows: Forbid non-component Debug builds (see issue #2679)

→ <<cset a65fc8031333>>

We’re getting this error, seems related to this change.

ERROR at //build/config/compiler/compiler.gni:296:3: Assertion failed.
assert(symbol_level != 2 || current_toolchain != default_toolchain ||
^-----
Can't do non-component debug builds at symbol_level=2
See //BUILD.gn:12:1: whence it was imported.
import("//build/config/compiler/compiler.gni")
^--------------------------------------------
Traceback (most recent call last):
File "C:\dev\automate\upstream\src\cef\tools\gclient_hook.py", line 146, in <module>
RunAction(src_dir, cmd)
File "C:\dev\automate\upstream\src\cef\tools\gclient_util.py", line 35, in RunAction
gclient_utils.CheckCallAndFilter(
File "C:\dev\automate\depot_tools\gclient_utils.py", line 672, in CheckCallAndFilter
raise subprocess2.CalledProcessError(
subprocess2.CalledProcessError: Command 'gn gen out\Debug_GN_x86' returned non-zero exit status 1 in C:\dev\automate\upstream\src

This happens when running gclient_hook

@ Shezan Baig: What GN_DEFINES are you using?

If you follow the MasterBuildQuickStart instructions (is_component_build=true) or the AutomatedBuildSetup instructions (is_official_build=true use_thin_lto=false) then you shouldn’t see this error.

@Marshall Greenblatt I’m getting the same error as Shezan. And adding “use_thin_lto=false” (which I never used before and not quite sure what it does) as suggested in your reply, did not fix it (I tried using “GN_DEFINES=is_official_build=true use_thin_lto=false“. and It’s still failing in the pre-build phase while building the targets for debug mode bins even when not actually compiling in debug mode. I get the same error message as Shezan, The solution is to essentially override part of the changes in gn_args.py and I’m now using “GN_DEFINES=is_official_build=true use_thin_lto=false forbid_non_component_debug_build=false“ which works.

Can you explain in more detail how you’re building? Are you using the automate_git.py script? What are the contents of your out\Debug_GN_x86\args.gn file (if that’s the configuration that’s failing for you)?

Approaching this from a more basic perspective, setting GN_DEFINES and running gn_args.gy:

set GN_DEFINES=is_official_build=true
cd path\to\src\cef\tools
python gn_args.py


Gives the following output for out/Debug_GN_x86:

chrome_pgo_phase=0
clang_use_chrome_plugins=false
dcheck_always_on=true
enable_background_mode=false
enable_basic_printing=true
enable_nacl=false
enable_print_preview=true
enable_resource_allowlist_generation=false
enable_widevine=true
is_component_build=false
is_debug=false
is_official_build=true
optimize_webui=true
target_cpu="x86"


Writing those contents to out\Debug_GN_x86\args.gn and run gn gen:

set DEPOT_TOOLS_WIN_TOOLCHAIN=0
gn gen out\Debug_GN_x86


Succeeds for me:

Done. Made 17288 targets from 2827 files in 15660ms


Ah, looks like out/Debug_GN_x86_sandbox is failing with GN_DEFINES=is_official_build=true. Fix coming shortly.

Windows: Allow non-component Debug official sandbox builds (see issue #2679)

→ <<cset 2432333f982a>>

Windows: Allow non-component Debug official sandbox builds (see issue #2679)

→ <<cset 2804be0749ab>>

Windows: Allow non-component Debug official sandbox builds (see issue #2679)

→ <<cset c95b2a1c4c32>>

Sorry about not mentioning it was while building the targets for debug sandbox. Actually I noticed it myself only after my comment.

Thanks, setting GN_DEFINES fixed the problem for me

It’s MG’s newest commit that fixed it. No need to change the GN_DEFINES on your side.