chromium: Update to 138.0.7204.35

[caneraltinbasak]

Chromium 138+ uses its bundled libc++ and compiler-rt. To ensure the build system uses these and does not fall back to system-provided runtime libraries, explicitly pass the target triple and disable system stdlib++.

This avoids linker errors caused by missing crtbeginS.o, crtendS.o, and libgcc when using Clang with a minimal sysroot.

Release Notes:
https://chromereleases.googleblog.com/2025/07/stable-channel-update-for-desktop_15.html

Build and patch changes:
Added patches:

0011-fix-check_version-Only-compare-node.js-major-version.patch Updated patches:

0009-Adjust-the-Rust-build-to-our-needs.patch
Removed patches:

0011-Disable-crabbyavif-to-fix-build-errors.patch
0012-Revert-Allow-and-use-std-hardware_destructive_interf.patch 0013-Revert-Set-Rust-symbol-visibility-to-hidden-when-C-s.patch 0014-pdfium-Fix-missing-PDFiumAPIStringBufferAdapter-temp.patch 0015-Revert-Connect-the-Rust-log-crate-to-the-base-loggin.patch License changes:
Added licenses:

third_party/compiler-rt/src/LICENSE.TXT
third_party/libtess2/LICENSE
third_party/llvm-libc/src/LICENSE.TXT
third_party/net/third_party/mozilla_security_manager/LICENSE Removed licenses:

third_party/accessibility-audit/LICENSE
third_party/io_grpc_grpc_api/LICENSE
third_party/libavifinfo/LICENSE
Updated licenses:

third_party/android_deps/libs/com_google_android_gms_play_services_auth/LICENSE → third_party/android_deps/autorolled/committed/libs/com_google_android_gms_play_services_auth/LICENSE third_party/android_deps/libs/com_google_android_gms_play_services_auth_api_phone/LICENSE → third_party/android_deps/autorolled/committed/libs/com_google_android_gms_play_services_auth_api_phone/LICENSE third_party/android_deps/libs/com_google_android_gms_play_services_auth_base/LICENSE → third_party/android_deps/autorolled/committed/libs/com_google_android_gms_play_services_auth_base/LICENSE third_party/android_deps/libs/com_google_android_gms_play_services_auth_blockstore/LICENSE → third_party/android_deps/autorolled/committed/libs/com_google_android_gms_play_services_auth_blockstore/LICENSE third_party/android_deps/libs/com_google_android_gms_play_services_fido/LICENSE → third_party/android_deps/autorolled/committed/libs/com_google_android_gms_play_services_fido/LICENSE third_party/android_deps/libs/com_google_android_libraries_identity_googleid_googleid/LICENSE → third_party/android_deps/autorolled/committed/libs/com_google_android_libraries_identity_googleid_googleid/LICENSE third_party/expat/src/expat/COPYING
third_party/libjpeg_turbo/LICENSE
Test-built
chromium-ozone-wayland

master, clang, MACHINE=qemux86-64
chromium-x11

master, clang, MACHINE=qemux86-64, qemuarm, qemuarm64 Repo hashes (from meta-chromium-test)
meta-oe:
commit: "a8dfd10600035a799abae03178fc7054582ea43d" poky:
commit: "243d54fd466f5f852cc0fdcce57997918ce35f32" meta-clang:
commit: "7a2f83360920b10214e2659e17a4b9cba2d0435b"

[caneraltinbasak]

Verified for x11, ozone for arm, aarch64 and x86-64:
https://github.com/brightsign/meta-browser/actions/runs/17671009313

[zboszor]

Build error from today, after oe-core switched to CLANG 21.1.0:

Log data follows:
| DEBUG: Executing shell function do_copy_clang_library
| cp: cannot create regular file '/mnt/zozo/yocto-5.3-arm/tmp-sicom/work/corei7-64-oe-linux/chromium-x11/138.0.7204.157/recipe-sysroot-native/usr/lib/clang/latest/lib/linux/libclang_rt.builtins-x86_64.a': No such file or directory
| WARNING: /mnt/zozo/yocto-5.3-arm/tmp-sicom/work/corei7-64-oe-linux/chromium-x11/138.0.7204.157/temp/run.do_copy_clang_library.1112517:157 exit 1 from 'cp "$lib_file" "/mnt/zozo/yocto-5.3-arm/tmp-sicom/work/corei7-64-oe-linux/chromium-x11/138.0.7204.157/recipe-sysroot-native/usr/lib/clang/latest/${stripped_lib_file}"'
| WARNING: Backtrace (BB generated script):
| 	#1: do_copy_clang_library, /mnt/zozo/yocto-5.3-arm/tmp-sicom/work/corei7-64-oe-linux/chromium-x11/138.0.7204.157/temp/run.do_copy_clang_library.1112517, line 157
| 	#2: main, /mnt/zozo/yocto-5.3-arm/tmp-sicom/work/corei7-64-oe-linux/chromium-x11/138.0.7204.157/temp/run.do_copy_clang_library.1112517, line 160

Please, fix it. FWIW, I use meta-intel and MACHINE="intel-corei7-64".

[caneraltinbasak]

Can you please try your target machine compile with following hashes checked out:

meta-oe: "a8dfd10600035a799abae03178fc7054582ea43d"
poky: "243d54fd466f5f852cc0fdcce57997918ce35f32"
meta-clang: "7a2f83360920b10214e2659e17a4b9cba2d0435b"

I've used the hashes Firefox was using for testing Whinlatter branch, they are 3 months old. I would like to land my changes as they are and do adaptations for the latest yocto release as a follow up change.

[OldManYellsAtCloud]

I think until than it should be kept as Walnascar-compatible only maybe. (If I remember well, those hashes are essentially the last Walnascar-compatible revisions after the actual Walnascar release, just before some breaking changes were introduced. FF has switched to the tip of master since then, though FF is a much smaller beast than Chromium)

[caneraltinbasak]

I think until than it should be kept as Walnascar-compatible only maybe. (If I remember well, those hashes are essentially the last Walnascar-compatible revisions after the actual Walnascar release, just before some breaking changes were introduced. FF has switched to the tip of master since then, though FF is a much smaller beast than Chromium)

That is fine. I can target my changes to walnascar branch, if a maintainer creates a walnascar branch.

[caneraltinbasak]

meta-oe: "a8dfd10600035a799abae03178fc7054582ea43d" poky: "243d54fd466f5f852cc0fdcce57997918ce35f32" meta-clang: "7a2f83360920b10214e2659e17a4b9cba2d0435b"

I've used the hashes Firefox was using for testing Whinlatter branch, they are 3 months old. I would like to land my changes as they are and do adaptations for the latest yocto release as a follow up change.

Sorry, I have to correct myself here. I checked again where these hashes are coming from. It is not Firefox, these are tip of meta-oe, poky and meta-clang as of 1st of July when I first started upgrading meta-chromium to Chromium138 and poky had layer name as whinlatter at the time.

I had vacation and other work interruptions in between...

[zboszor]

meta-oe: "a8dfd10600035a799abae03178fc7054582ea43d" poky: "243d54fd466f5f852cc0fdcce57997918ce35f32" meta-clang: "7a2f83360920b10214e2659e17a4b9cba2d0435b"
I've used the hashes Firefox was using for testing Whinlatter branch, they are 3 months old. I would like to land my changes as they are and do adaptations for the latest yocto release as a follow up change.

Sorry, I have to correct myself here. I checked again where these hashes are coming from. It is not Firefox, these are tip of meta-oe, poky and meta-clang as of 1st of July when I first started upgrading meta-chromium to Chromium138 and poky had layer name as whinlatter at the time.

I had no problems at around the beginning of summer either, but since then a lot of breaking changes were added to oe-core for clang and related recipes.

[adalessandro]

@caneraltinbasak pushed fixes on brightsign#15 , please review and merge.

[adalessandro]

@caneraltinbasak pushed fixes on brightsign#15 , please review and merge.

BTW, tested build using your hashes. In the above mentioned MR, added those hashes dependencies both in the README and commit log message:

Test dependencies:
------------------

* URI: git://git.yoctoproject.org/poky
  - branch: master
  - revision: 243d54fd466f5f852cc0fdcce57997918ce35f32

* URI: git://git.openembedded.org/meta-openembedded
  - layers: meta-oe
  - branch: master
  - revision: a8dfd10600035a799abae03178fc7054582ea43d

* URI: git://github.com/kraj/meta-clang
  - branch: master
  - revision: 7a2f83360920b10214e2659e17a4b9cba2d0435b

[caneraltinbasak]

I had a look at the PR and it has some merge conflicts. I can land them if you can fix them.

I think, this PR can be closed in favor of #923.
zboszor took my changes updated the recipe to Chromium140 with a later version of Whinlatter. #923 has this change and more. It is already approved...

[adalessandro]

I had a look at the PR and it has some merge conflicts. I can land them if you can fix them.

As we've already mentioned in brightsign#15 , that PR is to rebase and force push into this one. Feel free to review it and do any further changes if required, of course. My goal was to fix a few things, in order to push forward this PR.

I think, this PR can be closed in favor of #923. zboszor took my changes updated the recipe to Chromium140 with a later version of Whinlatter. #923 has this change and more. It is already approved...

Right, I've seen it. However, as this was not closed, I'm not against merging this version 138 bump first, sync the scarthgap branch as well (#921 and brightsign#16), then move to version 140.

Overall, this is just an attemp to push forward step by step, getting this to a stable point ASAP. The current state is pretty out-of-date and seems to be broken on several reported cases.

[caneraltinbasak]

I've now rebased on top of existing OSSystems:master and forced pushed onto brightsign:for/review/ossystems/master/138.0.7204.157

[adalessandro]

I've now rebased on top of existing OSSystems:master and forced pushed onto brightsign:for/review/ossystems/master/138.0.7204.157

I still think this needs a little bit more work before merging, not huge stuff, overall is fine. But there're a few things to fix, e.g. 1a9da86 subject is chromium: Update to 138.0.7204.35, but this updates to 138.0.7204.157. Let's wait for the fixes in brightsign#15 :-)

[adalessandro]

@MaxIhlenfeldt , @kraj , (and the rest of maintainers):

Do you think this is in a good shape now so we can move forward?
One thing to mention/discuss is that the README now includes the revision hash for the dependencies. As we've been having frequent breakage issues.

[adalessandro]

@MaxIhlenfeldt , @kraj , (and the rest of maintainers):

Do you think this is in a good shape now so we can move forward? One thing to mention/discuss is that the README now includes the revision hash for the dependencies. As we've been having frequent breakage issues.

@fbertux @rakuco @otavio any maintainer that could take a look at this one? In the case this is considered obsolete, please let us know and/or close the PR in favor of a different one. Any feedback would be great to move this recipe forward.

[adalessandro]

@MaxIhlenfeldt , @kraj , (and the rest of maintainers):
Do you think this is in a good shape now so we can move forward? One thing to mention/discuss is that the README now includes the revision hash for the dependencies. As we've been having frequent breakage issues.

@fbertux @rakuco @otavio any maintainer that could take a look at this one? In the case this is considered obsolete, please let us know and/or close the PR in favor of a different one. Any feedback would be great to move this recipe forward.

Thanks! Can we follow up now on #921