Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upCI build fails on iOS and MacOS: pdf_compositor.mojom.h not found. #8756
Assignees
Comments
mkarolin
added a commit
to brave/brave-core
that referenced
this issue
Mar 19, 2020
Fixes brave/brave-browser#8756 This appears to be an upstream bug. The Chromium change below added headless_content_utility_client.cc/h to the headless_renderer target but didn't add deps to pdf_compositor (like headless_non_renderer target does). Something else must have been building those targets earlier on iOS and MacOS (since the below change has been present since cr78), but not any longer. Chromium change: https://chromium.googlesource.com/chromium/src/+/4d4bd27f36db6c5d994c55cea90ae363a5593a01 commit 4d4bd27f36db6c5d994c55cea90ae363a5593a01 Author: Chris Davis <chrdavis@microsoft.com> Date: Tue Aug 13 04:58:45 2019 +0000 Link headless_renderer for chrome.dll when is_multi_dll_chrome=false A recent change made to enable is_multi_dll_chrome = false caused a regression for component builds where the crash export thunks were getting linked into chrome.dll instead of chrome_elf. Chrome.dll pulls in headless_shell_lib which on Windows depends on crash_export_thunks. This has the side-effect of statically linking these thunks into chrome.dll instead of having them be imported from chrome_elf.dll. The result of which is that the crash report database in chrome_elf.dll is never initialized. The bug only impacts component builds where is_multi_dll_chrome is set to false. Regression caused by: http://crrev.com/c/1697368 Bug: 991886
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Looks like an upstream bug. In https://chromium.googlesource.com/chromium/src/+/4d4bd27f36db6c5d994c55cea90ae363a5593a01 headless_content_utility_client.cc/h were added to the headless_renderer build target but the deps weren't.