061e2e5e73
* chore: bump chromium in DEPS to 113.0.5645.0 * chore: update patches/chromium/mas_avoid_usage_of_private_macos_apis.patch Xref: https://chromium-review.googlesource.com/c/chromium/src/+/4300129 Fix simple code shear * chore: update patches/chromium/build_only_use_the_mas_build_config_in_the_required_components.patch Xref: https://chromium-review.googlesource.com/c/chromium/src/+/4297496 Xref: https://chromium-review.googlesource.com/c/chromium/src/+/4327491 patch-fuzz update; no manual changes * chore: remove patches/chromium/fix_x11_window_restore_minimized_maximized_window.patch Xref: https://chromium-review.googlesource.com/c/chromium/src/+/4252946 Upstreamed by zcbenz, so local patch is no longer needed * chore: update chromium/printing.patch Xref: https://chromium-review.googlesource.com/c/chromium/src/+/4313019 Remove cookie parameter from PrintViewManagerBase::UpdatePrintSettings() * chore: remove NOTIMPLEMENTED BrowserProcessImpl::GetBreadcrumbPersistentStorageManager() Xref: https://chromium-review.googlesource.com/c/chromium/src/+/4247145 method removed upstream, so we do not need to add a stub for it in the subclass * chore: remove PrintViewManagerElectron::UpdatePrintSettings() Xref: https://chromium-review.googlesource.com/c/chromium/src/+/4313019 Previously, our implementation checked to see if we recognized the cookie param that was passed in. If so, we reported a bad message. Otherwise, we passed it up to the base class' UpdatePrintSettings(). CL4313019 removed the cookie param, so checking for a bad cookie param is no longer necessary / no longer possible. Since the only remaining task was to pass the work up to the base class, this commit removes the subclass implmentation entirely. * chore: update patches * chore: bump chromium in DEPS to 113.0.5647.0 * chore: bump chromium in DEPS to 113.0.5649.2 * chore: bump chromium in DEPS to 113.0.5651.0 * chore: update patches --------- Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com> Co-authored-by: Charles Kerr <charles@charleskerr.com> Co-authored-by: deepak1556 <hop2deep@gmail.com>
29 lines
1.2 KiB
Diff
29 lines
1.2 KiB
Diff
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
|
|
From: Cheng Zhao <zcbenz@gmail.com>
|
|
Date: Tue, 2 Aug 2022 11:53:00 +0900
|
|
Subject: fix: link with @loader_path/libffmpeg.dylib
|
|
|
|
Submitted to https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/3803946.
|
|
|
|
When building with `is_component_build=false is_component_ffmpeg=true`,
|
|
we must manually instruct executables to link with the ffmpeg.dylib,
|
|
which is generated at the @loader_path, where for most targets is the
|
|
out/{Release,Debug} dir.
|
|
|
|
Using @rpath is wrong because the @rpath of most targets does not
|
|
include the out dir, and the linker won't be able to find ffmpeg.dylib
|
|
because of so.
|
|
|
|
diff --git a/BUILD.gn b/BUILD.gn
|
|
index 91e2f508c38b711dd517346e0e2b520879940f50..f270c07f81bf72481f029a1e791dfec9f899cb48 100644
|
|
--- a/BUILD.gn
|
|
+++ b/BUILD.gn
|
|
@@ -453,7 +453,7 @@ if (is_component_ffmpeg) {
|
|
|
|
if (!is_component_build) {
|
|
if (is_mac) {
|
|
- ldflags += [ "-Wl,-install_name,@rpath/libffmpeg.dylib" ]
|
|
+ ldflags += [ "-Wl,-install_name,@loader_path/libffmpeg.dylib" ]
|
|
} else if (is_linux) {
|
|
all_dependent_configs = [
|
|
"//build/config/gcc:rpath_for_built_shared_libraries",
|