search

OSSystems / meta-browser

OpenEmbedded/Yocto BSP layer for Web Browsers
MIT License
185 stars 194 forks source link

chromium: update to 112.0.5615.121 #706

Closed MaxIhlenfeldt closed 1 year ago

MaxIhlenfeldt commented 1 year ago

Release notes: https://chromereleases.googleblog.com/2023/04/stable-channel-update-for-desktop.html (112.0.5615.49) https://chromereleases.googleblog.com/2023/04/stable-channel-update-for-desktop_14.html (112.0.5615.121)

Build and patch changes:

Add 0017-Revert-WebUI-Update-Rollup-to-v3.12.0.patch to enable building with Node 12. We also need to re-generate the third_party/node_modules after applying this patch for it to have an effect, thus modify chromium-gn.inc and add a do_update_node_modules task.

Add 0018-Revert-Fix-std-span-autodetection-7805.patch to enable building with clang 12.

Add 0019-Backport-Fix-deps-for-feed_response.proto.patch to fix a race condition in the build due to a missing dependency declaration. This can be dropped when we update to 113.

Add 0020-Only-default-operator-on-declaration.patch to enable building with clang12, which doesn't implement P2085R0 and therefore requires all defaulted operator== implementations to be defined on the first declaration.

Rebase remaining patches.

License changes:

Added licenses:

Removed licenses:

Updated licenses:

Test-built:

** Please note that Chromium requires clang version to be >= 12. For that, when on dunfell branch, use the latest meta-clang/dunfell-clang12 branch.

MaxIhlenfeldt commented 1 year ago

Regarding 0018-Revert-Fix-std-span-autodetection-7805.patch, I don't actually know why it's needed. Chromium has its own version of libc++, and that includes <span>. But for some reason, I got this error when trying to build dunfell:

| ../../third_party/flatbuffers/src/include/flatbuffers/stl_emulation.h:55:12: fatal error: 'span' file not found
|   #include <span>
|            ^~~~~~
| 1 error generated.

I suppose we could fix this upstream by re-introducing the __has_include(<span>) check, but first I'd like to find out why this requires a fix in the first place.

simonjhaggett commented 1 year ago

Hi, I've had a go at testing these changes.

Add 0017-Revert-WebUI-Update-Rollup-to-v3.12.0.patch to enable building with Node 12. We also need to re-generate the third_party/node_modules after applying this patch for it to have an effect, thus modify chromium-gn.inc and add a do_update_node_modules task.

This may not always work. Since kirkstone, only fetch tasks are permitted network access by default (on build hosts with kernels capable of enforcing this). Whilst network access can be enabled for other tasks (e.g. do_update_node_modules[network] = "1"), the documentation doesn't recommend this. From https://docs.yoctoproject.org/4.0.8/migration-guides/migration-4.0.html#fetching-changes :

Recipes shouldn’t be accessing the network outside of do_fetch as it usually undermines fetcher source mirroring, image and licence manifests, software auditing and supply chain security.

On my setup (Yocto v4.0.6 on Ubuntu 22.04), the do_update_node_modules task failed with npm ERR! request to https://registry.npmjs.org/rollup failed, reason: getaddrinfo EAI_AGAIN registry.npmjs.org. I am able to successfully complete the build if I remove both the 0017 patch and the do_update_node_modules task.

Also, it would be good if the recipes could be updated to build Chromium 112.0.5615.121. This version has a fix for a recently reported high severity CVE (currently being widely reported):

https://nvd.nist.gov/vuln/detail/CVE-2023-2033

rakuco commented 1 year ago

Regarding 0018-Revert-Fix-std-span-autodetection-7805.patch, I don't actually know why it's needed.

Could it be some host part of the build, or the fact that we don't use Chromium's libc++ but rather meta-clang's, which can be quite old depending on the branch you're using?

MaxIhlenfeldt commented 1 year ago

Hi, I've had a go at testing these changes.

Thanks!

This may not always work. Since kirkstone, only fetch tasks are permitted network access by default (on build hosts with kernels capable of enforcing this). Whilst network access can be enabled for other tasks (e.g. do_update_node_modules[network] = "1"), the documentation doesn't recommend this.

TIL. The listed reasons are all valid, and I have to admit that I was already not too happy with this approach in the first place. I'm not sure what the best alternative that doesn't need network access would be. I haven't tried it yet, but maybe we could add https://registry.npmjs.org/rollup/-/rollup-2.58.0.tgz to SRC_URI and then modify do_update_node_modules (which should probably get a new name in this case) to replace the contents of third_party/node/node_modules/rollup with the contents of that tarball?

On my setup (Yocto v4.0.6 on Ubuntu 22.04) [...] I am able to successfully complete the build if I remove both the 0017 patch and the do_update_node_modules task.

That's expected, that patch is only needed for dunfell, because kirkstone and all later releases use a recent enough version of Node (>= 14).

Also, it would be good if the recipes could be updated to build Chromium 112.0.5615.121.

Thanks for highlighting the importance of that release! I've started a test build to see if everything still works with that version.

MaxIhlenfeldt commented 1 year ago

Could it be [...] the fact that we don't use Chromium's libc++ but rather meta-clang's, which can be quite old depending on the branch you're using?

Ah, I wasn't aware of that! Yes, that sounds like it's the cause for the build failure, I suppose meta-clang/dunfell-clang12 ships a libc++ without <span>.

nrpt-m commented 1 year ago

@MaxIhlenfeldt , Once you push 112.0.5615.121 , I will start testing on kirkstone, mickledore & master branches.

MaxIhlenfeldt commented 1 year ago

I suppose meta-clang/dunfell-clang12 ships a libc++ without <span>.

Hm, https://github.com/llvm/llvm-project/blob/release/12.x/libcxx/include/span exists, though. And chrome/browser/extensions/pref_mapping.cc includes <span> as well, but that doesn't result in an error.

So something about the compilation of third_party/flatbuffers is different. Maybe it's that it gets built with clang++, not arm-oe-linux-gnueabi-clang++ (because we want to build flatc for the host for compiling flatbuffers). But I'm not sure why that would mean it can't find <span>?

kraj commented 1 year ago

I suppose meta-clang/dunfell-clang12 ships a libc++ without <span>.

Hm, https://github.com/llvm/llvm-project/blob/release/12.x/libcxx/include/span exists, though. And chrome/browser/extensions/pref_mapping.cc includes <span> as well, but that doesn't result in an error.

So something about the compilation of third_party/flatbuffers is different. Maybe it's that it gets built with clang++, not arm-oe-linux-gnueabi-clang++ (because we want to build flatc for the host for compiling flatbuffers). But I'm not sure why that would mean it can't find <span>?

for hosttools its using host provided headers mostly. Can you check the compiler commandline for failing compile and also post preprocessed file for the source file in question.

ekapllaj commented 1 year ago

Hi, I was trying to use this version on imx8mp on Honister branch, but having some trouble. I can only build it with _use_systemminigbm=false and _use_waylandgbm=false. Without these options I'm getting errors:

| aarch64-poky-linux-ld.lld: error: undefined symbol: gl::NativeViewGLSurfaceEGL::NativeViewGLSurfaceEGL(gl::GLDisplayEGL*, void*, std::__1::unique_ptr<gfx::VSyncProvider, std::__1::default_delete<gfx::VSyncProvider> >)
| >>> referenced by gl_surface_wayland.cc:35 (./../../ui/ozone/platform/wayland/gpu/gl_surface_wayland.cc:35)
| >>>               thinlto-cache/llvmcache-3739F71403891AB77722085AE00941D7F258F8C3:(ui::GLSurfaceWayland::GLSurfaceWayland(gl::GLDisplayEGL*, std::__1::unique_ptr<wl_egl_window, ui::EGLWindowDeleter>, ui::WaylandWindow*))
| clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
| ninja: build stopped: subcommand failed.

I had the same problem on version 111.0.5563.147 but passing the parameter "--disable-gpu" made chromium usable. The problem with version 112.x.x.x.x is that it segfaults, also by using "--disable-gpu"

So far I tried version 112.0.5615.49 and also 112.0.5615.112, both exit with segmentation fault.

I also tried to build it without patches: 

0017-Revert-WebUI-Update-Rollup-to-v3.12.0.patch
0018-Revert-Fix-std-span-autodetection-7805.patch
0019-Backport-Fix-deps-for-feed_response.proto.patch

Same behaviour, it immediately segfauls.

simonjhaggett commented 1 year ago

Also, it would be good if the recipes could be updated to build Chromium 112.0.5615.121.

Just FYI that a second high-severity CVE (currently being actively exploited) was reported in the past couple of days:

https://nvd.nist.gov/vuln/detail/CVE-2023-2136

From https://chromereleases.googleblog.com/2023/04/stable-channel-update-for-desktop_18.html, it appears that Linux users should now upgrade to 112.0.5615.165.

MaxIhlenfeldt commented 1 year ago

From https://chromereleases.googleblog.com/2023/04/stable-channel-update-for-desktop_18.html, it appears that Linux users should now upgrade to 112.0.5615.165.

Alright, I've confirmed that 112.0.5615.121 builds, and just now started a test build for 112.0.5615.165.

MaxIhlenfeldt commented 1 year ago

@kraj:

for hosttools its using host provided headers mostly. Can you check the compiler commandline for failing compile

| FAILED: yocto_native/obj/third_party/flatbuffers/compiler_files/idl_gen_dart.o
| clang++ -MMD -MF yocto_native/obj/third_party/flatbuffers/compiler_files/idl_gen_dart.o.d -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D_GNU_SOURCE -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DFLATBUFFERS_LOCALE_INDEPENDENT=0 -I../../third_party/flatbuffers/src/grpc -I../.. -Iyocto_native/gen -I../../third_party/flatbuffers/src/include -fno-delete-null-pointer-checks -fno-ident -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -fcrash-diagnostics-dir=../../tools/clang/crashreports -mllvm -instcombine-lower-dbg-declare=0 -ffp-contract=off -m64 -msse3 -Xclang -fdebug-compilation-dir -Xclang . -ftrivial-auto-var-init=pattern -O2 -fdata-sections -ffunction-sections -fno-unique-section-names -fno-omit-frame-pointer -g0 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wall -Wno-unused-variable -Wno-c++11-narrowing -Wno-unused-but-set-variable -Wno-misleading-indentation -Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi -Wloop-analysis -Wno-unneeded-internal-declaration -Wenum-compare-conditional -Wno-unknown-warning-option -Wno-ignored-pragma-optimize -Wno-deprecated-builtins -Wno-bitfield-constant-conversion -Wno-deprecated-this-capture -std=c++20 -Wno-trigraphs -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -isystem/home/gitlab-runner/yocto-chromium/builds/ci-chromium-x11-raspberrypi3-dunfell/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-oe-linux-gnueabi/chromium-x11/112.0.5615.49-r0/recipe-sysroot-native/usr/include   -isystem/home/gitlab-runner/yocto-chromium/builds/ci-chromium-x11-raspberrypi3-dunfell/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-oe-linux-gnueabi/chromium-x11/112.0.5615.49-r0/recipe-sysroot-native/usr/include   -O2 -pipe -c ../../third_party/flatbuffers/src/src/idl_gen_dart.cpp -o yocto_native/obj/third_party/flatbuffers/compiler_files/idl_gen_dart.o
| In file included from ../../third_party/flatbuffers/src/src/idl_gen_dart.cpp:18:
| In file included from ../../third_party/flatbuffers/src/src/idl_gen_dart.h:20:
| In file included from ../../third_party/flatbuffers/src/include/flatbuffers/code_generator.h:22:
| In file included from ../../third_party/flatbuffers/src/include/flatbuffers/idl.h:27:
| In file included from ../../third_party/flatbuffers/src/include/flatbuffers/flatbuffers.h:24:
| In file included from ../../third_party/flatbuffers/src/include/flatbuffers/array.h:23:
| ../../third_party/flatbuffers/src/include/flatbuffers/stl_emulation.h:55:12: fatal error: 'span' file not found
|   #include <span>
|            ^~~~~~
| 1 error generated.

and also post preprocessed file for the source file in question.

Do you want the output of clang++ -E? Is there an easy way to get that?

rakuco commented 1 year ago

Do you want the output of clang++ -E? Is there an easy way to get that?

If you use bitbake devshell <recipe> and go to the /out/Release and just run that compiler line above with -E it should work.

MaxIhlenfeldt commented 1 year ago

If you use bitbake devshell <recipe> and go to the /out/Release and just run that compiler line above with -E it should work.

Ah perfect, thanks! I have to recompile because I did some other things since the last failed build because of that error, but it shouldn't take too long.

MaxIhlenfeldt commented 1 year ago

Ok, I have another error now, but I think it stems from the same issue.

I built on another host than when I got the <span> errors, and I got this:

| FAILED: yocto_native/obj/third_party/boringssl/boringssl/ssl_versions.o
| clang++ -MMD -MF yocto_native/obj/third_party/boringssl/boringssl/ssl_versions.o.d -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D_GNU_SOURCE -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DBORINGSSL_IMPLEMENTATION -DBORINGSSL_ALLOW_CXX_RUNTIME -DBORINGSSL_NO_STATIC_INITIALIZER -DOPENSSL_SMALL -I../.. -Iyocto_native/gen -I../../third_party/boringssl/src/include -fno-delete-null-pointer-checks -fno-ident -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -fcrash-diagnostics-dir=../../tools/clang/crashreports -mllvm -instcombine-lower-dbg-declare=0 -ffp-contract=off -m64 -msse3 -Xclang -fdebug-compilation-dir -Xclang . -ftrivial-auto-var-init=pattern -fno-omit-frame-pointer -g0 -fvisibility=hidden -Wheader-hygiene-Wstring-conversion -Wtautological-overlap-compare -Wall -Wno-unused-variable -Wno-c++11-narrowing -Wno-unused-but-set-variable -Wno-misleading-indentation -Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi -Wloop-analysis -Wno-unneeded-internal-declaration -Wenum-compare-conditional -Wno-unknown-warning-option -Wno-ignored-pragma-optimize -Wno-deprecated-builtins -Wno-bitfield-constant-conversion -Wno-deprecated-this-capture -O2 -fdata-sections -ffunction-sections -fno-unique-section-names -std=c++20 -Wno-trigraphs -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -isystem/home/max/yocto-chromium/builds/ci-chromium-x11-raspberrypi3-dunfell/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-oe-linux-gnueabi/chromium-x11/112.0.5615.121-r0/recipe-sysroot-native/usr/include   -isystem/home/max/yocto-chromium/builds/ci-chromium-x11-raspberrypi3-dunfell/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-oe-linux-gnueabi/chromium-x11/112.0.5615.121-r0/recipe-sysroot-native/usr/include   -O2 -pipe -c ../../third_party/boringssl/src/ssl/ssl_versions.cc -o yocto_native/obj/third_party/boringssl/boringssl/ssl_versions.o
| In file included from ../../third_party/boringssl/src/ssl/ssl_versions.cc:15:
| In file included from ../../third_party/boringssl/src/include/openssl/ssl.h:145:
| In file included from ../../third_party/boringssl/src/include/openssl/base.h:501:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/memory:76:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:41:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/ostream:38:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/ios:42:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/ios_base.h:41:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/locale_classes.h:40:
| /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/string:127:6: error: use of undeclared identifier '__ops'; did you mean '__gnu_cxx::__ops'?
|                                         __ops::__pred_iter(std::ref(__pred)));
|                                         ^
| /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/predefined_ops.h:37:11: note: '__gnu_cxx::__ops' declared here
| namespace __ops
|           ^
| In file included from ../../third_party/boringssl/src/ssl/ssl_versions.cc:15:
| In file included from ../../third_party/boringssl/src/include/openssl/ssl.h:145:
| In file included from ../../third_party/boringssl/src/include/openssl/base.h:501:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/memory:76:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:41:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/ostream:38:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/ios:42:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/ios_base.h:41:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/locale_classes.h:40:
| /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/string:141:6: error: use of undeclared identifier '__ops'; did you mean '__gnu_cxx::__ops'?
|                                         __ops::__iter_equals_val(__value));
|                                         ^
| /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/predefined_ops.h:37:11: note: '__gnu_cxx::__ops' declared here
| namespace __ops
|           ^
| 2 errors generated.

Seems to me like we should be passing -stdlib=libc++ when compiling for the host? (I already tried doing on Tuesday by setting LIBCPLUSPLUS:class-native = "-stdlib=libc++" in chromium.inc, but I think that didn't do what I wanted it to.)

rakuco commented 1 year ago

It's been a while since I last had to touch the toolchain bits, so I don't recall if it was expected that the native part used host headers rather than stuff build for the host in meta-clang. @kraj probably has more insight here.

One thing: that clang++ above is the one from meta-clang, not your distro-provided one, right?

MaxIhlenfeldt commented 1 year ago

One thing: that clang++ above is the one from meta-clang, not your distro-provided one, right?

Yes, the host doesn't even have clang installed, i.e. if it weren't the one from meta-clang, clang++ wouldn't work.

rwmacleod commented 1 year ago

Are these clang errors only happening for dunfell ? Note that @nrpt-m is away tomorrow so he can start testing on Monday.

ekapllaj commented 1 year ago

I finally understood the cause of the segmentation fault. It was "--enable-wayland-ime" parameter. As soon as I start chromium with this parameter, it immediately segfaults!

This is a major regression issue on the embedded world since the virtual keyboard is the only input we have on a HMI machine.

I found the bug report on chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1431532

MaxIhlenfeldt commented 1 year ago

Are these clang errors only happening for dunfell ?

Yes. langdale and kirkstone both work fine without 0018-Revert-Fix-std-span-autodetection-7805.patch.

MaxIhlenfeldt commented 1 year ago

This is a major regression issue on the embedded world since the virtual keyboard is the only input we have on a HMI machine.

Please add that point of view to the discussion at the bug you linked, I think that specific concern hasn't been raised yet.

MaxIhlenfeldt commented 1 year ago

FYI, I'll probably be unable to work on this next week. If you want to land this earlier than the week after next, feel free to take over this PR :smile:

rwmacleod commented 1 year ago

@MaxIhlenfeldt I'm off next week too but @nrpt-m is available. On Monday, Narpat can update to 112.0.5615.165 and we can continue working on the dunfell build issue while you are away with @kraj . I wonder if it's time for meta-clang/dunfell-clang14 ?

kraj commented 1 year ago

@kraj do you know if there are any plans to update nodejs to a more recent version on dunfell? 12.x was EoL'ed a year ago upstream per https://github.com/nodejs/release#end-of-life-releases, and supporting nodejs v12 in this recipe is becoming increasingly difficult.

bumping major versions is out of policy in general for released layers. However, I am happy to consider adding additional recipe perhaps which is newer LTS of node with node 12 being default. However, someone will have to do that work of porting 14.x or 16.x or 18.x and testing it with dunfell.

kraj commented 1 year ago

I have added musl fixes and nodejs fixes on top of this pull here

https://github.com/OSSystems/meta-browser/pull/708

nrpt-m commented 1 year ago

@MaxIhlenfeldt Surprisingly, I have not observed any error while building chromium 112.0.5615.49 & 112.0.5615.121 for dunfell. I have also applied the musl fixes where I found some whitespace errors and nodejs fixes on top of these versions from #708 and built successfully. Here are the commits -> https://github.com/nrpt-m/meta-browser/commits/112.0.5615.165

Now, updated to chromium 112.0.5615.165 and started the build for master & dunfell branches.

nrpt-m commented 1 year ago

Next: chromium: update to 112.0.5615.165 #709

MaxIhlenfeldt commented 1 year ago

Closed in favour of #709.