The current ebuild for chromium-128.0.6613.137 fails to build on ppc64le. This happens on both 4K and 64K page size machines. 64K page size: multiple 'ld.lld: error: duplicate symbol' errors 4K page size: 'FAILED: gen/net/data/ssl/chrome_root_store/chrome-root-store-inc.cc' If I modify the ebuild to use the most recent patch set from Raptor Engineering's quickbuild.io and to only apply the patches 'chromium-ppc64-libpng.patch' and 'libpng-pdfium-compile-98.patch' from 'chromium-ppc64le-gentoo-patches-1.tar.xz', the package will build, install and run successfully on my 64K page machine but still fails on my 4K page machine. Toggling the 'custom-cflags' USE flag doesn't seem to make a difference. Reproducible: Always
Created attachment 903896 [details] modified ebuild
Created attachment 903913 [details] build log 4k
Created attachment 903914 [details] build log 64k
Created attachment 903915 [details] emerge info 4k
Created attachment 903916 [details] emerge info 64k
Quick update: It seems that the file 'use-sysconf-page-size-on-ppc64.patch' from the Raptor / Solid Silicon patch set is causing the build failure on my 4K page system. Currently, I'm building chromium without the aforementioned patch and I've already gotten further in the process than with the patch. Will report back when / if the build has completed. URLs for the patch: https://gitlab.solidsilicon.io/public-development/open-source/chromium/openpower-patches/-/blob/chromium-128/patches/ppc64le/third_party/use-sysconf-page-size-on-ppc64.patch https://gitlab.solidsilicon.io/public-development/open-source/chromium/openpower-patches/-/blob/chromium-127/patches/ppc64le/third_party/use-sysconf-page-size-on-ppc64.patch
Interesting. I'll keep an eye out and we can update the ebuild. I'm waiting on their 129 patchset, too.
Created attachment 904024 [details] personal overlay archive for chromium A patchset for the 129 versions is already out at: https://gitlab.solidsilicon.io/public-development/open-source/chromium/openpower-patches/-/tree/chromium-129/patches In order to see whether my issues are specific to chromium 128 versions, I adapted the ebuild for chromium-129.0.6668.58 to use the patches from the link above. (see attachment) One Debian specific patch is still required that isn't included in the Solid Silicon repo. (included in the attachement) The situation is pretty much the same as with version 128: Builds on 64K pages, fails on 4K pages. At the moment, I'm unable to tell whether removing the "offending" patch 'use-sysconf-page-size-on-ppc64.patch' works on 4K pages or not, because the build hasn't finished yet... A word of caution: The modified ebuild in the attached archive removes the file 'use-sysconf-page-size-on-ppc64.patch' unconditional of page size which is quite likely a bad idea. How would one check for page size in an ebuild? Just use 'getconf PAGE_SIZE' or is there a more elegant way?
Created attachment 904253 [details] updated overlay archive After compiling and running chromium versions 128.0.6613.137, 129.0.6668.58 and 129.0.6668.70 on both 64K and 4K pages systems, I'd suggest not applying the following patches: "${WORKDIR}/ppc64le/fix-breakpad-compile.patch" "${WORKDIR}/ppc64le/fix-swiftshader-compile.patch" "${WORKDIR}/debian/patches/ppc64le/third_party/use-sysconf-page-size-on-ppc64.patch" (for 128 versions) "${WORKDIR}/openpower-patches-chromium-129-patches/patches/ppc64le/third_party/use-sysconf-page-size-on-ppc64.patch" (for 129 versions) The first two patches in the list are outdated and at least the swiftshader patch causes build errors. More recent versions of these patches are included in the patchset from Raptor / Solid Silicon anyway. The removal of the third patch isn't necessary for a successful build an a 64K pages system, but on a 4K pages system the build will fail with this patch applied. On a 64K pages system, the build will finish successfully with or without the patch.
Ack. I'm doing the 129 stable bump now, will update the ppc64 patches based on your feedback and make that available. Thanks for your work. Feel free to log a bug that just hands me a solution any day :)
You're very welcome. Thank you, too, for all your efforts as a maintainer. Looking forward to see the changes in the repo.
I'm going to hold off on this for a little while while I work out what to do about the scary llvm miscompilation warnings in the new patchset. On my radar, looks like we may need to backport some patches first, but I do need to get the new build out to other arches.
Matt, I've seen the warning on the SSC gitlab instance regarding clang / llvm. But since I couldn't reproduce the issue using clang 18, I didn't bother to even mention it in this bug report. In hindsight, this wasn't a clever move by me. Apologies for that. I've been using clang 18 to build various chromium versions on ppc64le since early August and I've not been able to observe the described massive consumption of system ressources and random crashes.
Created attachment 907122 [details] overlay archive witch chromium 128, 129 and 130 Solid Silicon released a patchset for the 130 series, so I updated the ebuilds for ppc64le. There's also some clarification on the clang/llvm issues: https://gitlab.solidsilicon.io/public-development/open-source/chromium/openpower-patches/-/tree/chromium-130 It seems LLVM 18.1.8 / LLVM 19.1.1 or higher are safe to use. Presonally, I've been using clang/llvm 18.1.8 to build chromium since early August. That's probably why I haven't encountered the high system usage / crashes.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44eb4ce25290e217fe5269df63ff03016890adc7 commit 44eb4ce25290e217fe5269df63ff03016890adc7 Author: Matt Jolly <kangie@gentoo.org> AuthorDate: 2024-11-02 04:24:16 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-11-02 04:24:22 +0000 www-client/chromium: drop 128.0.6613.137 Old, vulnerable. Only kept around for ppc64 and broken even there. Bug: https://bugs.gentoo.org/940304 Signed-off-by: Matt Jolly <kangie@gentoo.org> www-client/chromium/Manifest | 5 - www-client/chromium/chromium-128.0.6613.137.ebuild | 1452 -------------------- 2 files changed, 1457 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=96f83c07970601e0b57d03d4830d9000f76c9bdc commit 96f83c07970601e0b57d03d4830d9000f76c9bdc Author: Matt Jolly <kangie@gentoo.org> AuthorDate: 2024-11-02 04:15:23 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-11-02 04:23:38 +0000 www-client/chromium: keyword 130.0.6723.91 for ~ppc64 Move source for ppc64le patchset from raptor engineering to openPOWER. Drop our ppc64le tarball (which has dwindled over time) in favour of conditional application of patches from our chromium-patches tarball, something that was probably long overdue. Bug: https://bugs.gentoo.org/940304 Reported-by: zin0 <z_i_n_o@bluewin.ch> Signed-off-by: Matt Jolly <kangie@gentoo.org> www-client/chromium/Manifest | 3 +- www-client/chromium/chromium-130.0.6723.91.ebuild | 52 +++++++++++++++-------- 2 files changed, 36 insertions(+), 19 deletions(-)
Hi, It took a little while but here it is: an up-to-date Chromium ppc64le ebuild. I know that the patches apply but I haven't gone further than that. Could you let me know how you go? Thanks for all of the work you put into getting this info together!
Created attachment 908002 [details, diff] patch for rust-clanglib The new ebuild isn't working for me. 1. We need the following patch: 'rust-clanglib.patch' (see attachement). Without this patch, the build process will fail at an early stage. This patch is included in the patch series from Raptor Engineering's quickbuild instance as a Debian specific patch but not in Solid Silicon's gitlab instance. (It is, in fact, a Debian and not a Raptor / Solid Silicon patch.) Up to now, I kept this patch in the "${FILESDIR}" of my personal overlay. Could this patch be included in the Gentoo chromium-patches tarball? (The patch is for version 128 but works without modification for 129 and 130.) 2. The patch 'baseline-isa-3-0.patch' (only used if USE="cpu_flags_ppc_vsx3") doesn't apply on my system(s). I need to investigate further on this one, but that's lowest on my priority list. 3. Compile failure on 4K page systems, again, because of 'use-sysconf-page-size-on-ppc64.patch' . Generally, I'm not sure wether I like the new way of applying the openpower-patches. Personally, I'd prefer the old way of getting the patch names from the 'series' file in "${WORKDIR}/openpower-patches-${PPC64_HASH}/patches". It would make it easier to filter out unneeded / unwanted patches such as the ones that are commented out in that file.
Created attachment 908003 [details] modified chromium-130.0.6723.91.ebuild The attached ebuild is onyl a preliminary proposal. It will only work with USE="-cpu_flags_ppc_vsx3" and if 'rust-clanglib.patch' is placed into '/etc/portage/patches/www-client/chromium' .
Created attachment 908746 [details] chromium-130.0.6723.116-r1.ebuild The attached ebuild addresses the problems mentioned in comment #17: Apply 'baseline-isa-3-0.patch' after the other OpenPOWER patches (if USE="cpu_flags_ppc_vsx3"). Don't apply 'use-sysconf-page-size-on-ppc64.patch' if pagesize is 4K. Get patch names from '${WORKDIR}/openpower-patches-${PPC64_HASH}/patches/series' and filtering out the commented ones before applying them. The remaining issue is 'rust-clanglib.patch' from comment #17. It would be great for it to be included in the Gentoo chromium-patches tarball. (Place the patch in '/etc/portage/patches/www-client/chromium' for now.)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=02d53ccb0e3d4f1d09ece02f107e1a14b2af6788 commit 02d53ccb0e3d4f1d09ece02f107e1a14b2af6788 Author: Matt Jolly <kangie@gentoo.org> AuthorDate: 2024-11-17 08:41:52 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-11-17 10:45:16 +0000 www-client/chromium: update ppc64 handling in 133 - Use Solid Silicon patches - Get patch order from sources - Add missing debian rust patch to chromium-tarballs (from Raptor patchset) Bug: https://bugs.gentoo.org/940304 Signed-off-by: Matt Jolly <kangie@gentoo.org> www-client/chromium/Manifest | 2 +- www-client/chromium/chromium-133.0.6835.3.ebuild | 43 +++++++++++++++++------- 2 files changed, 32 insertions(+), 13 deletions(-)
I've updated 133 based on this feedback. I don't know if the solidsilicon patches actually apply, but do take a look anyway and let me know if anything has been missed.
Created attachment 908981 [details, diff] chromium-133.0.6835.3.ebuild.diff Thanks, the ebuild looks ok to me, except for two things: IUSE="cpu_flags_ppc_vsx3" seems to be missing and the page size check does the opposite of what it is supposed to do. (See attached diff) The OpenPOWER patches, however, don't apply (the first one to fail is 'HACK-debian-clang-disable-skia-musttail.patch'). This is to be expected. The patches are specific to major chromium versions and simply won't work on newer versions of chromium. I've been using chromium on ppc64le since January 2023 and I can't remember OpenPOWER patches written for one major chromium version ever beeing succesfully applied to a newer major version. As a consequence, I would highly recommend to only have a ppc64/~ppc64 keyword for chromium versions to which a corresponding OpenPOWER patchset exists. The most recent one would currently be chromium-130.
Created attachment 908983 [details] chromium-130.0.6723.116-r1.ebuild update
> I would highly recommend to only have a ppc64/~ppc64 keyword for chromium versions to which a corresponding OpenPOWER patchset exists. The most recent one would currently be chromium-130. That's typically what we do. I'll get the 133 build updated when we get our next dev channel release and we'll keyword it when it hits stable and have an updated patchset to apply. There's no patchset for 131 yet, but maybe we can backport these changes when that happens.
> chromium-130.0.6723.116-r1.ebuild update Please consider `diff` to upload changes; the Chromium ebuilds are nearing 1500 lines long and it's a lot to dig through to identify what the actual changes are and what I need to merge (besides, if I'm lucky they can be automatically applied).
