Closed MaxIhlenfeldt closed 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 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.
@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
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.
@MaxIhlenfeldt @rakuco , Have completed the builds & testing in dunfell branch for all these below systems and all the systems worked well except rpi4.
chromium-ozone-wayland: qemux86-64
chromium-x11: qemux86-64, qemuarm, qemuarm64, raspberrypi4-64**
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 ?
@nrpt-m yes on RPi4/dunfell the "network service crashed" problem is still there.
@MaxIhlenfeldt , Have completed the builds & testing in master branch for all these below systems and all the systems worked well except qemuarm.
chromium-ozone-wayland: qemux86-64
chromium-x11: qemux86-64, qemuarm**, qemuarm64, raspberrypi4-64
** 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.
@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.
chromium-ozone-wayland: qemux86-64
chromium-x11: qemux86-64, qemuarm, qemuarm64, raspberrypi4-64**
**Once @rwmacleod complete the testing of rpi4 image, I will update here.
Next, I have started the builds with mickledore branch.
I am getting below errors while building for qemuarm machine.
I've searched the source code, but I've found no #define
s for _TIME_BITS
, and only four #undef
s 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?
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?
Attached the log file for some more details about the errors. chromium-114.0.5735.198-build-errors.txt
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
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.
@MaxIhlenfeldt, Have completed the builds & testing in mickledore branch for all these below systems and all the systems worked well.
chromium-ozone-wayland: qemux86-64
chromium-x11: qemux86-64, qemuarm, qemuarm64, raspberrypi4-64
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
@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 #undef
s _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
(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 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
#undef
s_FILE_OFFSET_BITS
which doesn't play well with glibc 2.34's bminor/glibc@47f24c2 and the newly-introduced checks infeatures-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.
(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)
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?
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 ?
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.
@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?)
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.
Thank you everyone for reviewing, building, testing, and fixing the ARM build error!
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:
chromium-ozone-wayland:
chromium-x11
** 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