Windows LLD build broken by swiftshader bundling change |
||||
Issue descriptionFirst failing build: https://build.chromium.org/p/chromium.fyi/builders/CrWinClangLLD64/builds/4653 The mini installer packing action doesn't find libGLESv2.dll: FAILED: chrome.7z setup.ex_ gen/chrome/installer/mini_installer/mini_installer/packed_files.rc C:/b/depot_tools/python276_bin/python.exe ../../chrome/tools/build/win/create_installer_archive.py --build_dir . --staging_dir gen/chrome/installer/mini_installer/mini_installer --input_file ../../chrome/installer/mini_installer/chrome.release --resource_file_path gen/chrome/installer/mini_installer/mini_installer/packed_files.rc --target_arch=x64 --distribution=_google_chrome --output_dir . --chrome_runtime_deps gen/chrome_component.runtime_deps --setup_runtime_deps gen/setup.runtime_deps --enable_hidpi=1 --component_build=1 --depfile gen/chrome/installer/mini_installer/archive.d Traceback (most recent call last): File "../../chrome/tools/build/win/create_installer_archive.py", line 659, in <module> sys.exit(main(options)) File "../../chrome/tools/build/win/create_installer_archive.py", line 551, in main options.chrome_runtime_deps, current_version) File "../../chrome/tools/build/win/create_installer_archive.py", line 507, in DoComponentBuildTasks shutil.copy(component_dll, version_dir) File "C:\b\depot_tools\python276_bin\lib\shutil.py", line 119, in copy copyfile(src, dst) File "C:\b\depot_tools\python276_bin\lib\shutil.py", line 82, in copyfile with open(src, 'rb') as fsrc: IOError: [Errno 2] No such file or directory: '.\\swiftshader/libGLESv2.dll' The change: https://codereview.chromium.org/2715563002 Probably there is some gn setting confusion about building libglesv2 under lld on Windows. I see a few other crbugs about ThinLTO and LLD not working with swiftshader/libGLESv2: http://crbug.com/686980 http://crbug.com/672718 The args.gn file to reproduce: """ clang_use_chrome_plugins = false is_clang = true is_component_build = true is_debug = false strip_absolute_paths_from_debug_symbols = true symbol_level = 1 use_lld = true """
,
Mar 20 2017
,
Mar 20 2017
There's a weird behavior here I haven't figured out yet: When building using this configuration, libGLESv2.dll and libEGL.dll end up in the wrong directory. The output_dir variable doesn't seem to be respected. These libraries should end up in <output dir>\swiftshader\ and they end up in <output dir>\. Angle and SwiftShader end up overwriting each other. Here's an example of the output_dir being specified: https://cs.chromium.org/chromium/src/third_party/swiftshader/src/OpenGL/libGLESv2/BUILD.gn?l=59
,
Mar 20 2017
Appears to be an LLD bug: http://bugs.llvm.org/show_bug.cgi?id=32354
,
Mar 20 2017
I debugged this, and found that the issue is that LLD gives the library name found in the .def file higher precedence than the one specified on the command line. It sets the output file name flag when processing /OUT:swiftshader/libGLESv2.dll, and then again when processing /DEF:../../third_party/swiftshader/src/OpenGL/libGLESv2/libGLESv2.def.
,
Mar 20 2017
Thanks rnk@ for looking into this. It looks like an LLD issue to me. As long as the library name is respected, we should be able to change the output directory somehow without modifying the .def file. Is there any workaround other than modifying the .def file?
,
Mar 20 2017
I have a patch to just fix LLD. These bots are testing top-of-tree lld anyway, so they will get the fix soon. Nobody is shipping chrome builds with coff lld yet.
,
Mar 21 2017
Let's see if the bots cycle green when they pick up r298327 tomorrow. We'll also need a V8 roll to get past http://crbug.com/703028
,
Mar 21 2017
Bot's green again. Thanks! |
||||
►
Sign in to add a comment |
||||
Comment 1 by r...@chromium.org
, Mar 17 2017