component builds mini_installer missing CRT libraries
Reported by
robrich...@gmail.com,
Feb 15 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3010.0 Safari/537.36 Steps to reproduce the problem: 1. perform a Chromium component build (on just Windows 10 perhaps?) 2. error on generating chrome.7z + mini_installer.exe What is the expected behavior? ninja to generate chrome.7z archive and mini_installer.exe installer What went wrong? ninja reports api-ms-win-crt-environment-l1-1-0.dll and/or similar CRT libraries are missing Did this work before? N/A Chrome version: 58.0.3013.0 Channel: n/a OS Version: 10.0 Flash Version: not installed I am using Clang+LLD to build, though I suspect component builds using MSVS would be affected as well. The build box is running Windows 10 10.0.14393 with current VS2015u3 and SDK 14393.795 installed. The immediate solution (for me) was to manually copy the libraries from the default CRT directory (for x86 or x64 respectively) to the Chromium output build directory. C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\ Once the CRT libraries are copied, chrome.7z and mini_installer.exe are generated by ninja as expected.
,
Mar 10 2017
I independently discovered this while working on crbug.com/683729 . I have some ideas for fixes.
,
Mar 11 2017
,
Mar 13 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/46cd6d9361fffc104929e0ed654576eb3b286f14 commit 46cd6d9361fffc104929e0ed654576eb3b286f14 Author: brucedawson <brucedawson@chromium.org> Date: Mon Mar 13 21:12:31 2017 Copy *all* UCRT DLLs to the output directory In component builds where DEPOT_TOOLS_WIN_TOOLCHAIN=0 the VS toolchain script would copy *most* of the UCRT DLLs, but not all of them. It would fail to copy the api-ms-win-crt-*.dll files. This was not noticed because these only need to be copied in if you make the mini_installer target, and if you had previously done generated your output directory with DEPOT_TOOLS_WIN_TOOLCHAIN=1 then the files would be copied in then, and retained. This changes the script to copy from %WINDOWSSDKDIR%\Redist\ucrt\DLLs directory, or the default location if this variable is not set. This path is used elsewhere, why copy_cdb_to_output.py and is supported by both values of DEPOT_TOOLS_WIN_TOOLCHAIN. If the SDK is installed in a non-default location then DEPOT_TOOLS_WIN_TOOLCHAIN=0 users will have to ensure that WINDOWSSDKDIR is set. Local testing confirms that the set of files copied is now identical for DEPOT_TOOLS_WIN_TOOLCHAIN=0/1 (the file versions are different due to SDK updates but that is known and expected). BUG= 692300 Review-Url: https://codereview.chromium.org/2743423002 Cr-Commit-Position: refs/heads/master@{#456484} [modify] https://crrev.com/46cd6d9361fffc104929e0ed654576eb3b286f14/build/vs_toolchain.py
,
Mar 13 2017
This should be working now. Let me know if you encounter any problems.
,
Mar 16 2017
Working. Thanks! |
||||
►
Sign in to add a comment |
||||
Comment 1 by ajha@chromium.org
, Feb 20 2017Labels: TE-NeedsTriageHelp