chromium: Update to 138.0.7204.35 (scarthgap)

[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.

scarthgap branch of meta-oe ships with clang18. meta-lts-mixins with scarthgap-clang20
branch should be included in layer.conf

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: "491671faee11ea131feab5a3a451d1a01deb2ab1"
poky:
commit: "ac257900c33754957b2696529682029d997a8f28"
meta-clang:
commit: "76596813cd0061bd9818a80926e6900af61fcaa0"
meta-lts-mixins:
commit: "96deb45139df027473faf0938fe006d33c45c375"

[caneraltinbasak]

Verified here:
https://github.com/brightsign/meta-browser/actions/runs/17671839632

[san-skov-dk]

If I use meta-lts-mixins hash 8ed4bf1919453f20d33c492897f93164dc69f4a8 (rust/cargo 1.88)
I can compile it on my targets i.MX6 based cortexa9t2hf-neon and i.MX8 based cortexa53-crypto

But if I update to latest meta-lts-mixins with rust/cargo 1.89. The following happens

| error: hiding a lifetime that's elided elsewhere is confusing
| --> ../../third_party/rust/chromium_crates_io/vendor/qr_code-v2/src/lib.rs:219:17
| |
| 219 | pub fn iter(&self) -> QrCodeIterator {
| | ^^^^^ -------------- the same lifetime is hidden here
| | |
| | the lifetime is elided here
| |
| = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
| note: the lint level is defined here
| --> ../../third_party/rust/chromium_crates_io/vendor/qr_code-v2/src/lib.rs:8:9
| |
| 8 | #![deny(warnings)]
| | ^^^^^^^^
| = note: #[deny(mismatched_lifetime_syntaxes)] implied by #[deny(warnings)]
| help: use '_ for type paths
| |
| 219 | pub fn iter(&self) -> QrCodeIterator<'> {
| | ++++
|
| error: hiding a lifetime that's elided elsewhere is confusing
| --> ../../third_party/rust/chromium_crates_io/vendor/qr_code-v2/src/optimize.rs:112:22
| |
| 112 | pub fn new(data: &[u8]) -> Parser {
| | ^^^^^ ------ the same lifetime is hidden here
| | |
| | the lifetime is elided here
| |
| = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
| help: use '_ for type paths
| |
| 112 | pub fn new(data: &[u8]) -> Parser<'> {
| | ++++
|
| error: aborting due to 2 previous errors
|
| [1590/14681] arm-pmc-linux-gnueabi-clang++ -

[caneraltinbasak]

Old code does not compile with new Rust. Changes are tested with
meta-lts-mixins: "96deb45139df027473faf0938fe006d33c45c375"

Chromium uses always uses latest compilers, the issue is probably fixed upstream. The fix needs to be backported if aim is to always stay on tip of the tree of the branches on all required layers. I don't know what is meta-browser's strategy on this.

[san-skov-dk]

@kraj @otavio Do you the strategy?
The PR works by creation. Then meta-lts-mixins got updated, which courses it not to work.

[OldManYellsAtCloud]

I am not talking for meta-chromium folks, nor trying to suggest anything - but maybe this is useful for anyone with anything: for Firefox I include in the readme which Rust version from which repository was used to test compile the browser: https://github.com/OSSystems/meta-browser/tree/master/meta-firefox (scroll to the table in the middle)
Not saying that I wouldn't look into issues reported with other versions, but I intend this as a baseline for the users, what they can expect to work.

[adalessandro]

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

[adalessandro]

@caneraltinbasak pushed fixes on brightsign#16 , 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: scarthgap
  - revision: ac257900c33754957b2696529682029d997a8f28

* URI: git://git.openembedded.org/meta-openembedded
  - layers: meta-oe
  - branch: scarthgap
  - revision: 491671faee11ea131feab5a3a451d1a01deb2ab1

* URI: git://github.com/kraj/meta-clang
  - branch: scarthgap-clang20
  - revision: 76596813cd0061bd9818a80926e6900af61fcaa0

* URI: git://git.yoctoproject.org/meta-lts-mixins
  - branch: scarthgap/rust
  - revision: 96deb45139df027473faf0938fe006d33c45c375

[caneraltinbasak]

I've now rebased to tip of OSSystems:scarthgap and forced push onto brightsign:for/review/ossystems/scarthgap/138.0.7204.157

You should be able to land my changes now.

[adalessandro]

I've now rebased to tip of OSSystems:scarthgap and forced push onto brightsign:for/review/ossystems/scarthgap/138.0.7204.157

You should be able to land my changes now.

Same comment as in #920 , please let's wait until this is properly fixed for the final submission.

[adalessandro]

@MaxIhlenfeldt , @kraj ,

This should be in a good state, at least as good as the master update. Let's discuss on #920 (comment) , once merged 🤞 we can follow up with this one.

[adalessandro]

@MaxIhlenfeldt , @kraj ,

This should be in a good state, at least as good as the master update. Let's discuss on #920 (comment) , once merged 🤞 we can follow up with this one.

@kraj @otavio this is a follow up of #920 , backporting to scarthgap.

[otavio]

I'm not a big fan of using fixed hashes, so I prefer not to modify the readme in this aspect. However, you can include a note in the readme indicating that the compiler may require some adjustments. I'm okay with adding such a note, but I don't agree with using fixed hashes.

[adalessandro]

I'm not a big fan of using fixed hashes, so I prefer not to modify the readme in this aspect. However, you can include a note in the readme indicating that the compiler may require some adjustments. I'm okay with adding such a note, but I don't agree with using fixed hashes.

Me neither, but as we've had so many build errors recently, I think that should be noted somewhere. But yeah, let me add a note in the README.
FYI, the commit you just got merged in master 25b6e5e added fixed hashes in the same way. I guess that should be amended as well.

[adalessandro]

@otavio I've pushed the following branch (as I don't have the rights to rebase this MR from @caneraltinbasak ), which fixis the README for this MR https://github.com/adalessandro/meta-browser/tree/for/review/ossystems/scarthgap/138.0.7204.157
@caneraltinbasak feel free to rebase your branch with this change, or @otavio feel free to just merge it if you agree with it. Thanks!

[adalessandro]

I'm not a big fan of using fixed hashes, so I prefer not to modify the readme in this aspect. However, you can include a note in the readme indicating that the compiler may require some adjustments. I'm okay with adding such a note, but I don't agree with using fixed hashes.

Me neither, but as we've had so many build errors recently, I think that should be noted somewhere. But yeah, let me add a note in the README. FYI, the commit you just got merged in master 25b6e5e added fixed hashes in the same way. I guess that should be amended as well.

FWIW, pushed #936 to fix the README in master branch.

[adalessandro]

@caneraltinbasak please rebase your branch once more :-) as I've rebased https://github.com/adalessandro/meta-browser/tree/for/review/ossystems/scarthgap/138.0.7204.157 to be in sync with the target scarthgap branch. No more conflicts now.