Closed MaxIhlenfeldt closed 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.
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):
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?
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.
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>
.
@MaxIhlenfeldt , Once you push 112.0.5615.121 , I will start testing on kirkstone, mickledore & master branches.
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>
?
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 withclang++
, notarm-oe-linux-gnueabi-clang++
(because we want to buildflatc
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.
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.
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.
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.
@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?
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 -E
it should work.
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.
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.)
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?
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.
Are these clang errors only happening for dunfell ? Note that @nrpt-m is away tomorrow so he can start testing on Monday.
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
Are these clang errors only happening for dunfell ?
Yes. langdale and kirkstone both work fine without 0018-Revert-Fix-std-span-autodetection-7805.patch
.
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.
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:
@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 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.
I have added musl fixes and nodejs fixes on top of this pull here
@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.
Next: chromium: update to 112.0.5615.165 #709
Closed in favour of #709.
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:
third_party/android_deps/libs/com_google_android_play_core_common/LICENSE
third_party/android_deps/libs/com_google_android_play_feature_delivery/LICENSE
https://chromium-review.googlesource.com/c/chromium/src/+/4226920
third_party/android_rust_toolchain/toolchain/share/doc/rust/LICENSE-APACHE
https://chromium-review.googlesource.com/c/chromium/src/+/4275302
third_party/devtools-frontend/src/front_end/third_party/lit/LICENSE
https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4060452
third_party/devtools-frontend/src/front_end/third_party/puppeteer/LICENSE
https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4275342
Removed licenses:
third_party/android_deps/libs/com_google_android_play_core/LICENSE
https://chromium-review.googlesource.com/c/chromium/src/+/4233789
third_party/android_deps/libs/org_jetbrains_annotations/LICENSE
third_party/android_deps/libs/org_jetbrains_kotlin_kotlin_stdlib/LICENSE
third_party/android_deps/libs/org_jetbrains_kotlin_kotlin_stdlib_common/LICENSE
https://chromium-review.googlesource.com/c/chromium/src/+/4226232
Updated licenses:
third_party/android_deps/libs/com_google_android_gms_play_services_basement/LICENSE
third_party/android_deps/libs/com_google_android_gms_play_services_tasks/LICENSE
https://chromium-review.googlesource.com/c/chromium/src/+/4226920
third_party/fontconfig/src/COPYING
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/3ae08a8, https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/74f0595, https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/23cede3, https://chromium-review.googlesource.com/c/chromium/src/+/4251898
third_party/hyphenation-patterns/LICENSE
https://chromium-review.googlesource.com/c/chromium/src/+/4189277
Test-built:
chromium-ozone-wayland:
chromium-x11
** Please note that Chromium requires clang version to be >= 12. For that, when on dunfell branch, use the latest meta-clang/dunfell-clang12 branch.