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.

Clean download with

automate-git.py --download-dir=d:\chrome --depot-tools-dir=d:\chrome\depot_tools --no-distrib --no-build --force-update --force-clean --branch=3770

then building with

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

python automate-git.py --download-dir=d:\chrome --depot-tools-dir=d:\chrome\depot_tools --no-distrib --no-update --force-build --branch=3770 --x64-build

Comments (19)

  1. Marshall Greenblatt

    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.

  2. Harshil Rajeshbhai Shah

    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 ?

  3. Marshall Greenblatt

    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.

  4. Shezan Baig

    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

  5. Bernard de Champlain

    @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.

  6. Marshall Greenblatt

    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
    

  7. Marshall Greenblatt

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

  8. Bernard de Champlain

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

  9. Bernard de Champlain

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

  10. Log in to comment