search

OSSystems / meta-browser

OpenEmbedded/Yocto BSP layer for Web Browsers
MIT License
183 stars 189 forks source link

chromium: Update to 114.0.5735.198 #729

Closed MaxIhlenfeldt closed 1 year ago

MaxIhlenfeldt commented 1 year ago

Release notes: https://chromereleases.googleblog.com/2023/06/stable-channel-update-for-desktop_26.html

Build and patch changes:

None.

License changes:

None.

Test-built:

** Please note that Chromium requires below set-up when on dunfell branch.

*** Please note that there currently is a problem on RPi4/dunfell where Chromium's network service crashes.

Signed-off-by: Max Ihlenfeldt max@igalia.com

MaxIhlenfeldt commented 1 year ago

@nrpt-m as I still have problems building dunfell on my machines, could you please do a dunfell build to confirm it still works with this version?

nrpt-m commented 1 year ago

@nrpt-m as I still have problems building dunfell on my machines, could you please do a dunfell build to confirm it still works with this version?

Sure, will build and let you know.

nrpt-m commented 1 year ago

@MaxIhlenfeldt Have successfully built dunfell/rpi4 image without any issue and other systems builds are going on. I have observed these below license warnings in dunfell builds. Have also observed in last update as well but, I have missed to mention.

WARNING: chromium-x11-114.0.5735.198-r0 do_populate_lic: chromium-x11: No generic license file exists for: LGPL-2.0-or-later in any provider WARNING: chromium-x11-114.0.5735.198-r0 do_populate_lic: chromium-x11: No generic license file exists for: LGPL-2.1-or-later in any provider WARNING: core-image-sato-1.0-r0 do_rootfs: The license listed LGPL-2.0-or-later was not in the licenses collected for recipe chromium-x11 WARNING: core-image-sato-1.0-r0 do_rootfs: The license listed LGPL-2.1-or-later was not in the licenses collected for recipe chromium-x11

MaxIhlenfeldt commented 1 year ago

Thanks! Regarding the warning, I think we can ignore it. It happened before (see https://github.com/OSSystems/meta-browser/pull/654) and I don't think its causing any problems.

nrpt-m commented 1 year ago

@MaxIhlenfeldt @rakuco , Have completed the builds & testing in dunfell branch for all these below systems and all the systems worked well except rpi4.

Next will start with master, kirkstone and mickledore branches. **@rwmacleod , could you please let us know, if that "network service crashed" problem is still there or not with this latest chromium ?

rwmacleod commented 1 year ago

@nrpt-m yes on RPi4/dunfell the "network service crashed" problem is still there.

nrpt-m commented 1 year ago

@MaxIhlenfeldt , Have completed the builds & testing in master branch for all these below systems and all the systems worked well except qemuarm.

** I am getting below errors while building for qemuarm machine.

$less /buildarea/eng1/chromium/build-chrom114/master-new/tmp/work/cortexa15t2hf-neon-poky-linux-gnueabi/chromium-x11/114.0.5735.198-r0/temp/log.do_compile.3419342 | grep error: /buildarea/eng1/chromium/build-chrom114/master-new/tmp/work/cortexa15t2hf-neon-poky-linux-gnueabi/chromium-x11/114.0.5735.198-r0/recipe-sysroot/usr/include/features-time64.h:26:5: error: "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" /buildarea/eng1/chromium/build-chrom114/master-new/tmp/work/cortexa15t2hf-neon-poky-linux-gnueabi/chromium-x11/114.0.5735.198-r0/recipe-sysroot/usr/include/features-time64.h:26:5: error: "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" /buildarea/eng1/chromium/build-chrom114/master-new/tmp/work/cortexa15t2hf-neon-poky-linux-gnueabi/chromium-x11/114.0.5735.198-r0/recipe-sysroot/usr/include/features-time64.h:26:5: error: "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" /buildarea/eng1/chromium/build-chrom114/master-new/tmp/work/cortexa15t2hf-neon-poky-linux-gnueabi/chromium-x11/114.0.5735.198-r0/recipe-sysroot/usr/include/features-time64.h:26:5: error: "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" $

Could you please check what could be the issue.

nrpt-m commented 1 year ago

@MaxIhlenfeldt , Have completed the builds & testing in kirkstone branch for all these below systems and all the systems worked well except rpi4. @rwmacleod is testing the kirkstone/rpi4 image.

**Once @rwmacleod complete the testing of rpi4 image, I will update here.

Next, I have started the builds with mickledore branch.

MaxIhlenfeldt commented 1 year ago

I am getting below errors while building for qemuarm machine.

I've searched the source code, but I've found no #defines for _TIME_BITS, and only four #undefs for _FILE_OFFSET_BITS [1], all of which seem to have been there for some time already.

I think clang should print the include path (i.e. which Chromium header included features-time64.h, possibly transitively) some where close to the error message. That might help identify the problem, could you please paste it here?

[1] https://source.chromium.org/search?q=%22undef%20_FILE_OFFSET_BITS%22&sq=&ss=chromium%2Fchromium%2Fsrc

nrpt-m commented 1 year ago

I think clang should print the include path (i.e. which Chromium header included features-time64.h, possibly transitively) some where close to the error message. That might help identify the problem, could you please paste it here?

[1] https://source.chromium.org/search?q=%22undef%20_FILE_OFFSET_BITS%22&sq=&ss=chromium%2Fchromium%2Fsrc

Attached the log file for some more details about the errors. chromium-114.0.5735.198-build-errors.txt

MaxIhlenfeldt commented 1 year ago

Thanks! So it is third_party/zlib/gzguts.h after all. But I still don't understand why this error has been introduced by updating to 114.0.5735.198, nothing in the changelist looks related to me [1].

Is it possible that something else in the build environment changed? Can you do a 114.0.5735.133 build under the same conditions to confirm that that still works?

[1] https://chromium.googlesource.com/chromium/src/+log/114.0.5735.133..114.0.5735.198?n=10000

nrpt-m commented 1 year ago

Is it possible that something else in the build environment changed? Can you do a 114.0.5735.133 build under the same conditions to confirm that that still works?

Sure, will check that as well. Now, mickledore build is going on so, once finishes I will try this.

nrpt-m commented 1 year ago

@MaxIhlenfeldt, Have completed the builds & testing in mickledore branch for all these below systems and all the systems worked well.

Is it possible that something else in the build environment changed? Can you do a 114.0.5735.133 build under the same conditions to confirm that that still works?

[1] https://chromium.googlesource.com/chromium/src/+log/114.0.5735.133..114.0.5735.198?n=10000

Have tried building the 114.0.5735.133 in the same environment and it failed with same errors. Have attached the error logs. chromium-114.0.5735.133-build-errors.txt

rakuco commented 1 year ago

@nrpt-m which branch is this again? I got confused by the comments above and it's not clear if this is happening on dunfell or something else.

I'm guessing something else changed in the toolchain but only a major glibc update comes to mind.

In any case, it looks like we're hitting https://github.com/madler/zlib/issues/447 -- for some reason zlib #undefs _FILE_OFFSET_BITS which doesn't play well with glibc 2.34's https://github.com/bminor/glibc/commit/47f24c21ee38701ae275aa9e451f70fa3e77478c and the newly-introduced checks in features-time64.h. One option would be something like this as suggested in the zlib issue:

diff --git a/third_party/zlib/gzguts.h b/third_party/zlib/gzguts.h
index e23f831f531bb..5b85ef7f95cb8 100644
--- a/third_party/zlib/gzguts.h
+++ b/third_party/zlib/gzguts.h
@@ -9,6 +9,7 @@
 #  endif
 #  ifdef _FILE_OFFSET_BITS
 #    undef _FILE_OFFSET_BITS
+#    undef _TIME_BITS
 #  endif
 #endif
rakuco commented 1 year ago

(alternatively, one could try adding zlib to chromium-unbundle.inc at the expense of turning off some zlib optimizations that are part of the Chromium tree)

nrpt-m commented 1 year ago

@nrpt-m which branch is this again? I got confused by the comments above and it's not clear if this is happening on dunfell or something else.

Sorry, I have updated the above comment and these errors are coming in master branch for qemuarm machine.

I'm guessing something else changed in the toolchain but only a major glibc update comes to mind.

In any case, it looks like we're hitting madler/zlib#447 -- for some reason zlib #undefs _FILE_OFFSET_BITS which doesn't play well with glibc 2.34's bminor/glibc@47f24c2 and the newly-introduced checks in features-time64.h. One option would be something like this as suggested in the zlib issue:

diff --git a/third_party/zlib/gzguts.h b/third_party/zlib/gzguts.h
index e23f831f531bb..5b85ef7f95cb8 100644
--- a/third_party/zlib/gzguts.h
+++ b/third_party/zlib/gzguts.h
@@ -9,6 +9,7 @@
 #  endif
 #  ifdef _FILE_OFFSET_BITS
 #    undef _FILE_OFFSET_BITS
+#    undef _TIME_BITS
 #  endif
 #endif

@rakuco , could you create the patch with this above change and give.

nrpt-m commented 1 year ago

(alternatively, one could try adding zlib to chromium-unbundle.inc at the expense of turning off some zlib optimizations that are part of the Chromium tree)

Have tried adding zlib to chromium-unbundle.inc but, it gives the below errors:

arm-poky-linux-gnueabi-ld.lld: error: unable to find library -lminizip clang-16: error: linker command failed with exit code 1 (use -v to see invocation)

rakuco commented 1 year ago

Have tried adding zlib to chromium-unbundle.inc but, it gives the below errors:

Thanks for testing, that was a guess, I'm not sure if anyone's been testing if this works upstream lately.

Could you try applying this patch (.patch version) on top of the one in this PR and see if it works?

nrpt-m commented 1 year ago

Thanks for testing, that was a guess, I'm not sure if anyone's been testing if this works upstream lately.

Could you try applying this patch (.patch version) on top of the one in this PR and see if it works?

Thanks, after applying this patch, the errors are gone while building the qemuarm machine in master branch. Do I need to build again all the machines in this branch only or all the branches ?

rakuco commented 1 year ago

Thanks, after applying this patch, the errors are gone while building the qemuarm machine in master branch.

:tada: thanks for testing!

Do I need to build again all the machines in this branch only or all the branches ?

I don't think you need to test other branches or architectures; the _TIME_BITS definition is coming from https://github.com/openembedded/openembedded-core/blob/master/meta/conf/distro/include/time64.inc, and 32-bit ARM seems to be the only architecture present there and which we also support.

rakuco commented 1 year ago

@MaxIhlenfeldt I think the above settles this issue, the patch just needs to be formatted and named properly. Since that specific build issue is not caused by this specific Chromium update, you could even land this fix separately (and restrict the patch to certain architectures like time64.inc does?)

MaxIhlenfeldt commented 1 year ago

you could even land this fix separately (and restrict the patch to certain architectures like time64.inc does?)

Sounds good, thanks for finding the fix! I'll send a PR with the patch tomorrow.

So I think this update is ready to be merged, as soon as I update the Test-built section? I'll do that tomorrow as well.

MaxIhlenfeldt commented 1 year ago

Thank you everyone for reviewing, building, testing, and fixing the ARM build error!