Raptor Engineering and the Talos II / ppc64 community have ported Chromium to ppc64le. All features of the browser appear to work at this time, including native v8 JIT, and patched builds exist for Debian [1] already. As this work was originally done in a manner that can be upstreamed to Google, the port is broken up into a series of small patches. Work is ongoing to merge these patches into the upstream Chromium project. A full list of patches is available on the RCS Wiki [2]; all of these patches with the exception of the GCC specific patches will need to be applied to enable builds on ppc64le systems. Note that big endian systems will not yet work; Chromium currently makes a number of endianness assumptions throughout its codebase. The patches currently apply to Chromium v70, and are continually maintained as part of the upstreaming efforts. Adding the patches and enabling builds for ppc64le will help provide a modern, fast browser for the nascent open computing community built on OpenPOWER products. [1] https://quickbuild.io/~raptor-engineering-public/+archive/ubuntu/chromium/ [2] https://wiki.raptorcs.com/wiki/Porting/Chromium
Thank you a lot, adding our chromium people to chime in :)
And the powerpc team as well.
I'm guessing these patches will break every chromium release, so I don't want to commit to maintaining this in the gentoo repository. I would suggest creating an overlay and maintaining it there.
Let see the status on gerrit, probably a power9/talos overlay would be useful.
gentoo's chromium ebuild was modified to support building with external patches and worked fine for a while using the following trick: https://gist.github.com/gyakovlev/e7c8ebf682c593352ac672892189ae18 Now I also created overlay where I maintain the patches so users are not required to patch anything and chromium is just 'emerge' away. https://github.com/gyakovlev/chromium-ppc64le <- overlay all credits go to original patchet creators and current maintainers at https://github.com/chromium-ppc64le/ I just juggle patches to fit into ebuild properly. Also planning to provide -bin versions a bit later, using above repo tarballs.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d90bb0c63080706dd3cc70587a29a06c72253a3c commit d90bb0c63080706dd3cc70587a29a06c72253a3c Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2021-05-18 03:41:02 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2021-05-19 15:09:31 +0000 www-client/chromium: add ppc64le patchset from void linux Closes: https://bugs.gentoo.org/669748 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/20861 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> www-client/chromium/Manifest | 1 + www-client/chromium/chromium-90.0.4430.212.ebuild | 9 +++++++-- 2 files changed, 8 insertions(+), 2 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63cd4f5df85da24e41ed65953c79457f401ae25d commit 63cd4f5df85da24e41ed65953c79457f401ae25d Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2021-05-18 03:51:42 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2021-05-19 15:09:31 +0000 profiles/arch/powerpc/ppc64: mask/unmask chromium on ppc64be/ppc64le Bug: https://bugs.gentoo.org/669748 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> profiles/arch/powerpc/ppc64/64le/package.mask | 4 ++++ profiles/arch/powerpc/ppc64/package.mask | 4 ++++ 2 files changed, 8 insertions(+)
Hi, is it still supported on ppc64le? There is no arch keyword and I get this error: https://bugs.gentoo.org/832803
(In reply to darkbasic from comment #7) > Hi, is it still supported on ppc64le? > There is no arch keyword and I get this error: https://bugs.gentoo.org/832803 Are you interested in maintaining the ppc64le patchset?
(In reply to Stephan Hartmann from comment #8) > (In reply to darkbasic from comment #7) > > Hi, is it still supported on ppc64le? > > There is no arch keyword and I get this error: https://bugs.gentoo.org/832803 > > Are you interested in maintaining the ppc64le patchset? Raptor has already started semi-officially maintaining the Chromium patchset for Debian, so if no one else has the time we might be able to step up and help here.
I did maintain a Fedora copr while I used the Blackbird as my main workstation in 2019 so I guess I could do so, but it will depend on wheter I will be able to keep using my Talos 2 or not. It's the third motherboard which gets replaced and in the first day of usage I'm already experiencing weird stuff with the new one like the GPU randomly not showing up in lspci or the usb drive disappearing while booting the Gentoo installer. If I end up getting a rock solid system that I can use as my daily driver I would gladly help to keep the ebuild in sync with the available patchsets, but if no one is still maintaining it "upstream" and non-trivial forward porting is required I fear it could be outside of my skills.
(In reply to darkbasic from comment #10) > I did maintain a Fedora copr while I used the Blackbird as my main > workstation in 2019 so I guess I could do so, but it will depend on wheter I > will be able to keep using my Talos 2 or not. > It's the third motherboard which gets replaced and in the first day of usage > I'm already experiencing weird stuff with the new one like the GPU randomly > not showing up in lspci or the usb drive disappearing while booting the > Gentoo installer. > If I end up getting a rock solid system that I can use as my daily driver I > would gladly help to keep the ebuild in sync with the available patchsets, > but if no one is still maintaining it "upstream" and non-trivial forward > porting is required I fear it could be outside of my skills. Sorry to hear that, never heard of anything like that before. I use several of these machines personally, powered on pretty much 24/7, zero problems. Can you Email me directly as I'd really like to see what's going on there... In any case, here at Raptor we're capable of keeping the main patchset working on ppc64le, so if you can just port those patches / maintain the Gentoo overlay that'd work quite well.
I'm just managed to build chromium 98 on ppc64le, but unfortunately it renders garbage. I've attached a tarball with the ebuild (and the patches) and a screenshot. Any idea how to fix it?
Created attachment 764685 [details] ebuild tarball
Created attachment 764686 [details] garbage rendering
(In reply to darkbasic from comment #12) > I'm just managed to build chromium 98 on ppc64le, but unfortunately it > renders garbage. I've attached a tarball with the ebuild (and the patches) > and a screenshot. Any idea how to fix it? If I had to guess, I'd say this issue could be in play: https://twitter.com/octaforge/status/1487867891915632643 "apparently there's an issue where fonts stop rendering with newer glibc (i think 2.34+) that's unsolved in my patchset (void's glibc is still 2.32 and i use musl myself)" Can you confirm you're on glibc 2.34+? If so, I'll see if I can reproduce and fix on this side.
Created attachment 764719 [details, diff] Candidate sandbox patch for font rendering Here's a candidate (untested) patch to potentially fix the font rendering on newer glibc versions. If you get a chance to test please let me know if it works or not. Thanks!
I'm using glibc 2.33 which is part of Gentoo's stable toolchain. I've tried with --no-sandbox and indeed it does fix the issue but unfortunately your tentative patch doesn't.
(In reply to darkbasic from comment #17) > I'm using glibc 2.33 which is part of Gentoo's stable toolchain. > I've tried with --no-sandbox and indeed it does fix the issue but > unfortunately your tentative patch doesn't. Understood. I'll get a test environment set up and work on getting this fixed.
(In reply to Timothy Pearson from comment #18) > Understood. I'll get a test environment set up and work on getting this > fixed. I have made some progress in understanding the issue and continue to work toward a fix. For anyone else working on similar problems, the font rendering issue is coming from the sandbox denying valid __NR_access (syscall 33) calls in regard to files in /etc/fonts (e.g. /etc/fonts/fonts.conf); it returns -EPERM instead. What is not fully understood at this point is why only ppc64 seems to affected, especially since glibc appears to be using the same call paths for both amd64 and ppc64le.
Reopening bug since I stopped maintaining chromium on ppc64le due to rapid release cycle and there’s some activity.
Apparently Firefox doesn't build with the sandbox either: https://bugzilla.mozilla.org/show_bug.cgi?id=1754959 If you are aware of any patches please let me know. Hopefully once the JIT patches will finally merge upstream Firefox will be the best option for ppc64 (I doubt anything will ever get merged in Chrome). Unfortunately for me I will still need both.
Created attachment 764955 [details, diff] Fix ppc64le Chromuim font rendering on glibc 2.34 This ended up being at least two issues, one of which is Chromium basically relying on (desired) behavior accidentally caused by a performance optimization on x86. The two issues found are: 1.) The renderer sandbox, by design, prevents access to most filesystem data, including the fontconfig control files and fonts. Chromium relies on fontconfig being initialized early, before the renderers are forked, in order to load font data prior to the sandbox being applied to the renderer process. If CLONE_VM etc. are not set (effectively changing from fork() to vfork()), fontconfig is unable to determine that it has already been initialized in the renderer process and tries to reload its configuration, which then fails due to the sandbox profile. 2.) ppc64le still negates fd arguments for some reason. Negating the fstat argument back if less than zero allows the libraries to continue loading after the vfork() above
Works fine now, thanks! I'd like to maintain the ppc64 patches for the Chromium ebuild, how should I proceed to get them merged in the Gentoo repo?
You can do an overlay ofc, I’ll try importing this to gentoo repo soon too. If you can help me maintain chromium i can proxy for you in main repo. I simply lack time to maintain it on my own but with extra pair of hands we can do it. Did you figure out ffmpeg build issue btw (gentoo ebuild specific)? I think it needs to generate gni source similar to like I do it for vpx. Btw, qtwebengine alsoo needs this patch, I’ll add it to patchset as I still maintain it. Thanks Timothy for finding the issue :)
Is there any way I can create a MR for the main Gentoo repo? I think that would be easier for both of us in the long term. In the meantime I've merged ppc64le support for electron, vscode and ungoogled-chromium into the PF4Public overlay: https://github.com/PF4Public/gentoo-overlay/pull/134 If you feel like these changes are good enough I will create a MR for www-client/chromium on the main repo (or do you still manage contributions via mailing lists?). There are also other patches I'd like to contribute like sci-physics/bullet By the way if you are aware of anybody who managed to compile Android Studio for ppc64le please let me know. I just need it to fetch the Android SDK to develop react-native applications, but I guess the SDK itself won't be ppc64le compatible. I even tried to run Android Studio inside a qemu x64 chroot, but it doesn't go past the splash screen despite using a 4K kernel.
Timothy could you please have a look at the following core dump? Electron 16 (based on Chromium 96) works fine and Chromium 98 works fine as well, but Electron 17 (based on Chromium 98) segfaults: $ electron-17 Electron 17.0.1 - Build cross platform desktop apps with JavaScript, HTML, and CSS Usage: electron [options] [path] A path to an Electron app may be specified. It must be one of the following: - index.js file. - Folder containing a package.json file. - Folder containing an index.js file. - .html/.htm file. - http://, https://, or file:// URL. Options: -i, --interactive Open a REPL to the main process. -r, --require Module to preload (option can be repeated). -v, --version Print the version. -a, --abi Print the Node ABI version. [471643:0227/000628.467204:ERROR:gpu_init.cc(454)] Passthrough is not supported, GL is egl, ANGLE is [471643:0227/000628.472150:ERROR:sandbox_linux.cc(377)] InitializeSandbox() called with multiple threads in process gpu-process. [471603:0227/000628.490654:ERROR:cursor_loader.cc(116)] Failed to load a platform cursor of type kNull Segmentation fault (core dumped) Core dump: https://drive.google.com/file/d/1l9qio2FeNLtBLyyDvhFfT_goITov70n9/view?usp=sharing
I've narrowed it down to wayland: --ozone-platform=x11 works fine while --ozone-platform=wayland doesn't. I previously didn't compile wayland support in electron 16 so it's safe to assume it wouldn't have worked either. This is weird because Chromium itself works fine with --ozone-platform=wayland.
Electron 16.0.8-2 had the same issue on Arch Linux x86_64 apparently, but somehow they've just fixed their Wayland support in their 17.1.0 PKGBUILD: https://github.com/archlinux/svntogit-community/commit/b3dcaee8cfcdf7a3e2f32169ea6a5586940cdacd I've compiled 17.1.0 but it still behaves the same way, so either they somehow fixed it with one of the patches in the previous diff (I couldn't figure out which one) or being on ppc might still trigger it somehow.
(In reply to darkbasic from comment #28) > Electron 16.0.8-2 had the same issue on Arch Linux x86_64 apparently, but > somehow they've just fixed their Wayland support in their 17.1.0 PKGBUILD: > https://github.com/archlinux/svntogit-community/commit/ > b3dcaee8cfcdf7a3e2f32169ea6a5586940cdacd > I've compiled 17.1.0 but it still behaves the same way, so either they > somehow fixed it with one of the patches in the previous diff (I couldn't > figure out which one) or being on ppc might still trigger it somehow. Are you sure the only fix is in Chromium, and that Wayland wasn't also updated / patched?
(In reply to darkbasic from comment #28) > Electron 16.0.8-2 had the same issue on Arch Linux x86_64 apparently, but > somehow they've just fixed their Wayland support in their 17.1.0 PKGBUILD: > https://github.com/archlinux/svntogit-community/commit/ > b3dcaee8cfcdf7a3e2f32169ea6a5586940cdacd > I've compiled 17.1.0 but it still behaves the same way, so either they > somehow fixed it with one of the patches in the previous diff (I couldn't > figure out which one) or being on ppc might still trigger it somehow. I don't have a native Wayland system available to test with, is there any way to get a standard text backtrace? Wondering if this might be part of the problem: https://github.com/electron/electron/issues/32436
> Are you sure the only fix is in Chromium, and that Wayland wasn't also updated / patched? They bumped electron to the same version I use in Gentoo and they applied some patches which seem unrelated to me. There were no other system updates, I verified by rebooting into a previous btrfs snapshot where electron wasn't working on wayland and I updated just electron, which fixed the issue. > I don't have a native Wayland system available to test with, is there any way to get a standard text backtrace? I'm not sure unfortunately. > Wondering if this might be part of the problem: It looks like it. What I don't understand is why it's fixed in my Arch Linux system while according to the bug report it doesn't look like so. This is especially weird because I've always used electron on wayland in my laptop, mostly without issues (but that was on KWin, not Mutter). Btw I've noticed that Chromium ppc64 does sigsegv sometimes: in can happen randomly (very rare, less so when the system is under high usage) or in a reproducible manner when loading some specific youtube videos. I'm compiling with clang because with gcc Chromium was excruciatingly slow and you couldn't even manage to play a youtube video.
I forward ported the patchset to Chromium 99, but unfortunately it doesn't build. You can find the new patches as well as my ebuild and the build log here: https://github.com/PF4Public/gentoo-overlay/pull/137
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a63d17729b1c44ed3bd7e34fe44ac6e1622661d2 commit a63d17729b1c44ed3bd7e34fe44ac6e1622661d2 Author: Stephan Hartmann <sultan@gentoo.org> AuthorDate: 2022-04-03 08:07:26 +0000 Commit: Stephan Hartmann <sultan@gentoo.org> CommitDate: 2022-04-03 08:08:22 +0000 www-client/chromium: add ppc64le patchset to stable channel Bug: https://bugs.gentoo.org/669748 Signed-off-by: Stephan Hartmann <sultan@gentoo.org> www-client/chromium/Manifest | 1 + www-client/chromium/chromium-100.0.4896.60.ebuild | 18 +++++++++++++++++- 2 files changed, 18 insertions(+), 1 deletion(-)
I have re-added the ppc64le patches without ~ppc64 keywords. It compiles in cross environment with clang, but can't do runtime testing. Please give it a try.
I'm sorry, I've missed the notification. Yes it works very well, but in order to compile with clang I had to enable the libcxx use flag, previously CHROMIUM_FORCE_LIBCXX was enough: https://wiki.gentoo.org/wiki/Chromium#Clang I think you can add the ~ppc64 use flag.
I've tried to patch Chromium 101 with Timothy's patchset but I get the following error: [6901/25532] python3.9 "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="powerpc64le-unknown-linux-gnu-nm" --sofile="./libvk_swiftshader.so" --tocfile="./libvk_swiftshader.so.TOC" --output="./libvk_swiftshader.so" -- clang++ -shared -Wl,-soname="libvk_swiftshader.so" -Wl,-Bsymbolic -Wl,--version-script=../../third_party/swiftshader/src/Vulkan/vk_swiftshader.lds -fuse-ld=lld -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,--no-call-graph-profile-sort -no-canonical-prefixes -rdynamic -Wl,-z,defs -Wl,--as-needed -nostdlib++ -Wl,-O1 -Wl,--as-needed -fuse-ld=lld -Wl,--as-needed -Wl,-z,relro,-z,now -o "./libvk_swiftshader.so" @"./libvk_swiftshader.so.rsp" FAILED: libvk_swiftshader.so libvk_swiftshader.so.TOC python3.9 "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="powerpc64le-unknown-linux-gnu-nm" --sofile="./libvk_swiftshader.so" --tocfile="./libvk_swiftshader.so.TOC" --output="./libvk_swiftshader.so" -- clang++ -shared -Wl,-soname="libvk_swiftshader.so" -Wl,-Bsymbolic -Wl,--version-script=../../third_party/swiftshader/src/Vulkan/vk_swiftshader.lds -fuse-ld=lld -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,--no-call-graph-profile-sort -no-canonical-prefixes -rdynamic -Wl,-z,defs -Wl,--as-needed -nostdlib++ -Wl,-O1 -Wl,--as-needed -fuse-ld=lld -Wl,--as-needed -Wl,-z,relro,-z,now -o "./libvk_swiftshader.so" @"./libvk_swiftshader.so.rsp" ld.lld: error: undefined symbol: llvm::MCAsmInfoXCOFF::MCAsmInfoXCOFF() >>> referenced by PPCMCAsmInfo.cpp >>> obj/third_party/swiftshader/third_party/llvm-10.0/swiftshader_llvm_ppc/PPCMCAsmInfo.o:(llvm::PPCXCOFFMCAsmInfo::PPCXCOFFMCAsmInfo(bool, llvm::Triple const&)) ld.lld: error: undefined symbol: llvm::MCAsmInfoXCOFF::isAcceptableChar(char) const >>> referenced by PPCMCAsmInfo.cpp >>> obj/third_party/swiftshader/third_party/llvm-10.0/swiftshader_llvm_ppc/PPCMCAsmInfo.o:(vtable for llvm::PPCXCOFFMCAsmInfo) ld.lld: error: undefined symbol: llvm::MCXCOFFObjectTargetWriter::MCXCOFFObjectTargetWriter(bool) >>> referenced by PPCXCOFFObjectWriter.cpp >>> obj/third_party/swiftshader/third_party/llvm-10.0/swiftshader_llvm_ppc/PPCXCOFFObjectWriter.o:(llvm::createPPCXCOFFObjectWriter(bool)) ld.lld: error: undefined symbol: llvm::MCXCOFFObjectTargetWriter::~MCXCOFFObjectTargetWriter() >>> referenced by PPCXCOFFObjectWriter.cpp >>> obj/third_party/swiftshader/third_party/llvm-10.0/swiftshader_llvm_ppc/PPCXCOFFObjectWriter.o:((anonymous namespace)::PPCXCOFFObjectWriter::~PPCXCOFFObjectWriter()) >>> referenced by PPCXCOFFObjectWriter.cpp >>> obj/third_party/swiftshader/third_party/llvm-10.0/swiftshader_llvm_ppc/PPCXCOFFObjectWriter.o:(vtable for (anonymous namespace)::PPCXCOFFObjectWriter) clang++: error: linker command failed with exit code 1 (use -v to see invocation) I've tried both with and without the patches to disable swiftshader. Any idea?
Can you change following line (third_party/swiftshader/third_party/llvm-10.0/llvm/include/llvm/MC/MCXCOFFObjectWriter.h) https://swiftshader.googlesource.com/SwiftShader/+/refs/heads/master/third_party/llvm-10.0/llvm/include/llvm/MC/MCXCOFFObjectWriter.h#23 to ~MCXCOFFObjectTargetWriter() override = default;
Unfortunately I still get the following (w/ the disable swiftshader patch): [6910/25532] python3.9 "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="powerpc64le-unknown-linux-gnu-nm" --sofile="./libvk_swiftshader.so" --tocfile="./libvk_swiftshader.so.TOC" --output="./libvk_swiftshader.so" -- clang++ -shared -Wl,-soname="libvk_swiftshader.so" -Wl,-Bsymbolic -Wl,--version-script=../../third_party/swiftshader/src/Vulkan/vk_swiftshader.lds -fuse-ld=lld -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,--no-call-graph-profile-sort -no-canonical-prefixes -rdynamic -Wl,-z,defs -Wl,--as-needed -nostdlib++ -Wl,-O1 -Wl,--as-needed -fuse-ld=lld -Wl,--as-needed -Wl,-z,relro,-z,now -o "./libvk_swiftshader.so" @"./libvk_swiftshader.so.rsp" FAILED: libvk_swiftshader.so libvk_swiftshader.so.TOC python3.9 "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="powerpc64le-unknown-linux-gnu-nm" --sofile="./libvk_swiftshader.so" --tocfile="./libvk_swiftshader.so.TOC" --output="./libvk_swiftshader.so" -- clang++ -shared -Wl,-soname="libvk_swiftshader.so" -Wl,-Bsymbolic -Wl,--version-script=../../third_party/swiftshader/src/Vulkan/vk_swiftshader.lds -fuse-ld=lld -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,--no-call-graph-profile-sort -no-canonical-prefixes -rdynamic -Wl,-z,defs -Wl,--as-needed -nostdlib++ -Wl,-O1 -Wl,--as-needed -fuse-ld=lld -Wl,--as-needed -Wl,-z,relro,-z,now -o "./libvk_swiftshader.so" @"./libvk_swiftshader.so.rsp" ld.lld: error: undefined symbol: llvm::MCAsmInfoXCOFF::MCAsmInfoXCOFF() >>> referenced by PPCMCAsmInfo.cpp >>> obj/third_party/swiftshader/third_party/llvm-10.0/swiftshader_llvm_ppc/PPCMCAsmInfo.o:(llvm::PPCXCOFFMCAsmInfo::PPCXCOFFMCAsmInfo(bool, llvm::Triple const&)) ld.lld: error: undefined symbol: llvm::MCAsmInfoXCOFF::isAcceptableChar(char) const >>> referenced by PPCMCAsmInfo.cpp >>> obj/third_party/swiftshader/third_party/llvm-10.0/swiftshader_llvm_ppc/PPCMCAsmInfo.o:(vtable for llvm::PPCXCOFFMCAsmInfo) ld.lld: error: undefined symbol: llvm::MCXCOFFObjectTargetWriter::MCXCOFFObjectTargetWriter(bool) >>> referenced by PPCXCOFFObjectWriter.cpp >>> obj/third_party/swiftshader/third_party/llvm-10.0/swiftshader_llvm_ppc/PPCXCOFFObjectWriter.o:(llvm::createPPCXCOFFObjectWriter(bool)) clang++: error: linker command failed with exit code 1 (use -v to see invocation)
--- a/third_party/swiftshader/third_party/llvm-10.0/BUILD.gn +++ b/third_party/swiftshader/third_party/llvm-10.0/BUILD.gn @@ -583,6 +583,7 @@ swiftshader_llvm_source_set("swiftshader_llvm_most") { "llvm/lib/MC/MCAsmInfoCOFF.cpp", "llvm/lib/MC/MCAsmInfoDarwin.cpp", "llvm/lib/MC/MCAsmInfoELF.cpp", + "llvm/lib/MC/MCAsmInfoXCOFF.cpp", "llvm/lib/MC/MCAsmMacro.cpp", "llvm/lib/MC/MCAsmStreamer.cpp", "llvm/lib/MC/MCAssembler.cpp",
[6505/25533] python3.9 ../../tools/protoc_wrapper/protoc_wrapper.py protos/perfetto/config/profiling/heapprofd_config.proto protos/perfetto/config/profiling/java_hprof_config.proto protos/perfetto/config/profiling/perf_event_config.proto --protoc ./protoc --proto-in-dir ../../third_party/perfetto/ --plugin protozero_plugin --plugin-out-dir gen/third_party/perfetto/ --plugin-options wrapper_namespace=pbzero [6506/25533] python3.9 "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="powerpc64le-unknown-linux-gnu-nm" --sofile="./libvk_swiftshader.so" --tocfile="./libvk_swiftshader.so.TOC" --output="./libvk_swiftshader.so" -- clang++ -shared -Wl,-soname="libvk_swiftshader.so" -Wl,-Bsymbolic -Wl,--version-script=../../third_party/swiftshader/src/Vulkan/vk_swiftshader.lds -fuse-ld=lld -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,--no-call-graph-profile-sort -no-canonical-prefixes -rdynamic -Wl,-z,defs -Wl,--as-needed -nostdlib++ -Wl,-O1 -Wl,--as-needed -fuse-ld=lld -Wl,--as-needed -Wl,-z,relro,-z,now -o "./libvk_swiftshader.so" @"./libvk_swiftshader.so.rsp" FAILED: libvk_swiftshader.so libvk_swiftshader.so.TOC python3.9 "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="powerpc64le-unknown-linux-gnu-nm" --sofile="./libvk_swiftshader.so" --tocfile="./libvk_swiftshader.so.TOC" --output="./libvk_swiftshader.so" -- clang++ -shared -Wl,-soname="libvk_swiftshader.so" -Wl,-Bsymbolic -Wl,--version-script=../../third_party/swiftshader/src/Vulkan/vk_swiftshader.lds -fuse-ld=lld -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,--no-call-graph-profile-sort -no-canonical-prefixes -rdynamic -Wl,-z,defs -Wl,--as-needed -nostdlib++ -Wl,-O1 -Wl,--as-needed -fuse-ld=lld -Wl,--as-needed -Wl,-z,relro,-z,now -o "./libvk_swiftshader.so" @"./libvk_swiftshader.so.rsp" ld.lld: error: undefined symbol: llvm::MCXCOFFObjectTargetWriter::MCXCOFFObjectTargetWriter(bool) >>> referenced by PPCXCOFFObjectWriter.cpp >>> obj/third_party/swiftshader/third_party/llvm-10.0/swiftshader_llvm_ppc/PPCXCOFFObjectWriter.o:(llvm::createPPCXCOFFObjectWriter(bool)) clang++: error: linker command failed with exit code 1 (use -v to see invocation)
Ignore the patch from comment #37. --- a/third_party/swiftshader/third_party/llvm-10.0/BUILD.gn +++ b/third_party/swiftshader/third_party/llvm-10.0/BUILD.gn @@ -133,7 +133,6 @@ swiftshader_llvm_source_set("swiftshader_llvm") { if (is_ubsan_vptr) { sources = [ "llvm/lib/MC/MCWasmObjectTargetWriter.cpp", - "llvm/lib/MC/MCXCOFFObjectTargetWriter.cpp", "llvm/lib/Target/ARM/MCTargetDesc/ARMTargetStreamer.cpp", "llvm/lib/Target/TargetIntrinsicInfo.cpp", ] @@ -583,6 +582,7 @@ swiftshader_llvm_source_set("swiftshader_llvm_most") { "llvm/lib/MC/MCAsmInfoCOFF.cpp", "llvm/lib/MC/MCAsmInfoDarwin.cpp", "llvm/lib/MC/MCAsmInfoELF.cpp", + "llvm/lib/MC/MCAsmInfoXCOFF.cpp", "llvm/lib/MC/MCAsmMacro.cpp", "llvm/lib/MC/MCAsmStreamer.cpp", "llvm/lib/MC/MCAssembler.cpp", @@ -637,6 +637,7 @@ swiftshader_llvm_source_set("swiftshader_llvm_most") { "llvm/lib/MC/MCWin64EH.cpp", "llvm/lib/MC/MCWinCOFFStreamer.cpp", "llvm/lib/MC/MCWinEH.cpp", + "llvm/lib/MC/MCXCOFFObjectTargetWriter.cpp", "llvm/lib/MC/MCXCOFFStreamer.cpp", "llvm/lib/MC/MachObjectWriter.cpp", "llvm/lib/MC/StringTableBuilder.cpp",
FYI I've opened discussion on chromium-dev on yet another upstream merge attempt. It might be helpful if the maintainers here chime in regarding the extra maintainance effort that is being expended downstream since Google is refusing to merge the self-contained patch sets? https://groups.google.com/a/chromium.org/g/chromium-dev/c/z5qbhoV-fNU
It works, thanks! You can find my chromium-101 ebuild for ppc64 here: https://github.com/PF4Public/gentoo-overlay/pull/152 @Timothy Thanks for your effort, I'll make sure to add my voice there. I'm also pretty sure that other maintainers are having bad times with Chromium, for example with 16K pages on arm64 (M1 Macs).
Chromium 102 ebuild: https://github.com/PF4Public/gentoo-overlay/pull/157
Any idea why with the v104 patchset libvpx ./generate_gni.sh fails like this? Create temporary directory. Generate config files. Remove temporary directory. Lint libvpx configuration. Create temporary directory. Generate source/config/linux/ia32/*_rtcd.h files. Generate source/config/linux/x64/*_rtcd.h files. Generate source/config/linux/arm/*_rtcd.h files. Generate source/config/linux/arm-neon/*_rtcd.h files. Generate source/config/linux/arm-neon-cpu-detect/*_rtcd.h files. Generate source/config/linux/arm64/*_rtcd.h files. Generate source/config/linux/arm-neon-highbd/*_rtcd.h files. Generate source/config/linux/arm64-highbd/*_rtcd.h files. Generate source/config/linux/mipsel/*_rtcd.h files. Generate source/config/linux/mips64el/*_rtcd.h files. Generate source/config/linux/ppc64/*_rtcd.h files. Generate source/config/linux/generic/*_rtcd.h files. Generate source/config/win/arm64/*_rtcd.h files. Generate source/config/win/ia32/*_rtcd.h files. Generate source/config/win/x64/*_rtcd.h files. Generate source/config/mac/ia32/*_rtcd.h files. Generate source/config/mac/x64/*_rtcd.h files. Generate source/config/ios/arm-neon/*_rtcd.h files. Generate source/config/ios/arm64/*_rtcd.h files. Generate source/config/nacl/*_rtcd.h files. Prepare Makefile. * ERROR: www-client/chromium-104.0.5112.101::darkbasic failed (prepare phase): * (no error message) * * Call stack: * ebuild.sh, line 127: Called src_prepare * environment, line 4986: Called die * The specific snippet of code: * ./generate_gni.sh || die; * * If you need support, post the output of `emerge --info '=www-client/chromium-104.0.5112.101::darkbasic'`, * the complete build log and the output of `emerge -pqv '=www-client/chromium-104.0.5112.101::darkbasic'`. * The complete build log is located at '/var/tmp/portage/www-client/chromium-104.0.5112.101/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/www-client/chromium-104.0.5112.101/temp/environment'. * Working directory: '/var/tmp/portage/www-client/chromium-104.0.5112.101/work/chromium-104.0.5112.101/third_party/libvpx' * S: '/var/tmp/portage/www-client/chromium-104.0.5112.101/work/chromium-104.0.5112.101' Running the same script manually from the build directory seems to work: talos2 /var/tmp/portage/www-client/chromium-104.0.5112.101/work/chromium-104.0.5112.101/third_party/libvpx # ./generate_gni.sh Create temporary directory. Generate config files. Remove temporary directory. Lint libvpx configuration. Create temporary directory. Generate source/config/linux/ia32/*_rtcd.h files. Generate source/config/linux/x64/*_rtcd.h files. Generate source/config/linux/arm/*_rtcd.h files. Generate source/config/linux/arm-neon/*_rtcd.h files. Generate source/config/linux/arm-neon-cpu-detect/*_rtcd.h files. Generate source/config/linux/arm64/*_rtcd.h files. Generate source/config/linux/arm-neon-highbd/*_rtcd.h files. Generate source/config/linux/arm64-highbd/*_rtcd.h files. Generate source/config/linux/mipsel/*_rtcd.h files. Generate source/config/linux/mips64el/*_rtcd.h files. Generate source/config/linux/ppc64/*_rtcd.h files. Generate source/config/linux/generic/*_rtcd.h files. Generate source/config/win/arm64/*_rtcd.h files. Generate source/config/win/ia32/*_rtcd.h files. Generate source/config/win/x64/*_rtcd.h files. Generate source/config/mac/ia32/*_rtcd.h files. Generate source/config/mac/x64/*_rtcd.h files. Generate source/config/ios/arm-neon/*_rtcd.h files. Generate source/config/ios/arm64/*_rtcd.h files. Generate source/config/nacl/*_rtcd.h files. Prepare Makefile. Generate X86 source list. Generate X86_64 source list. Generate ARM source list. Generate ARM NEON source list. Generate ARM NEON CPU DETECT source list. Generate ARM64 source list. Generate ARM NEON HighBD source list. Generate ARM64 HighBD source list. ARM64 Windows and Mac use the ARM64 Linux HighBD source list. No need to generate it. Generate MIPS source list. MIPS64 source list is identical to MIPS source list. No need to generate it. Generate ppc64 source list. Generate NaCl source list. Generate GENERIC source list. Remove temporary directory. Wrote formatted to '/var/tmp/portage/www-client/chromium-104.0.5112.101/work/chromium-104.0.5112.101/third_party/libvpx/libvpx_srcs.gni'. I didn't debug the script, I've just removed the || die from the ebuild and it compiled fine, but it's weird that it returns an error while not showing anything in the log.
Created attachment 801454 [details] chromium 104 ebuild I've removed > /dev/null from ./configure --target=generic-gnu in generate_gni.sh and now I've got this: Prepare Makefile. enabling vp8_encoder enabling vp8_decoder enabling vp9_encoder enabling vp9_decoder Configuring for target 'generic-gnu' enabling generic enabling webm_io enabling libyuv Toolchain is unable to link executables Configuration failed. This could reflect a misconfiguration of your toolchains, improper options selected, or another problem. If you don't see any useful error messages above, the next step is to look at the configure error log file (config.log) to determine what configure was trying to do when it died. I have no idea why the toolchain should be unable to link executables when running the script from the ebuild, but it works if I run it manually. I've attached the ebuild if someone wants to have a look.
I just remembered that I'm forcing clang for the chromium ebuild while my system defaults to gcc, that might explain why I get the error only when running the script from the ebuild: talos2 ~ # cat /etc/portage/env/compiler-clang LDFLAGS="${LDFLAGS} -fuse-ld=lld -rtlib=compiler-rt -unwindlib=libunwind -Wl,--as-needed" _HARDENING_FLAGS="-fstack-protector-strong -D_FORTIFY_SOURCE=2" CFLAGS="${CFLAGS} ${_HARDENING_FLAGS}" CXXFLAGS="${CXXFLAGS} ${_HARDENING_FLAGS}" LDFLAGS="${LDFLAGS} -Wl,-z,relro,-z,now" CC="clang" CXX="clang++" AR="llvm-ar" NM="llvm-nm" RANLIB="llvm-ranlib" talos2 ~ # cat /etc/portage/env/clang-chromium EXTRA_GN="use_lld=true is_clang=true clang_use_chrome_plugins=false" # # Needed with GCC 11 CHROMIUM_FORCE_LIBCXX=yes @Timothy Pearson do you use gcc or clang?
(In reply to darkbasic from comment #47) > I just remembered that I'm forcing clang for the chromium ebuild while my > system defaults to gcc, that might explain why I get the error only when > running the script from the ebuild: > > talos2 ~ # cat /etc/portage/env/compiler-clang > LDFLAGS="${LDFLAGS} -fuse-ld=lld -rtlib=compiler-rt -unwindlib=libunwind > -Wl,--as-needed" > > _HARDENING_FLAGS="-fstack-protector-strong -D_FORTIFY_SOURCE=2" > CFLAGS="${CFLAGS} ${_HARDENING_FLAGS}" > CXXFLAGS="${CXXFLAGS} ${_HARDENING_FLAGS}" > LDFLAGS="${LDFLAGS} -Wl,-z,relro,-z,now" > > CC="clang" > CXX="clang++" > AR="llvm-ar" > NM="llvm-nm" > RANLIB="llvm-ranlib" > > talos2 ~ # cat /etc/portage/env/clang-chromium > EXTRA_GN="use_lld=true is_clang=true clang_use_chrome_plugins=false" > # > # Needed with GCC 11 > CHROMIUM_FORCE_LIBCXX=yes > > @Timothy Pearson do you use gcc or clang? Clang 13. Build log: https://quickbuild.io/~raptor-engineering-public/+archive/ubuntu/chromium/+build/543303/+files/buildlog_ubuntu-bullseye-ppc64el.chromium_104.0.5112.101-1raptor0~deb11u1_UPLOADING.txt.gz
It looks like you don't run generate_gni.sh at all, while the Gentoo ebuild does: # we need to generate ppc64 stuff because upstream does not ship it yet # it has to be done before unbundling. if use ppc64; then pushd third_party/libvpx >/dev/null || die mkdir -p source/config/linux/ppc64 || die # requires git and clang, bug #832803 sed -i -e "s|^update_readme||g; s|clang-format|${EPREFIX}/bin/true|g" \ generate_gni.sh || die ./generate_gni.sh || die popd >/dev/null || die pushd third_party/ffmpeg >/dev/null || die cp libavcodec/ppc/h264dsp.c libavcodec/ppc/h264dsp_ppc.c || die cp libavcodec/ppc/h264qpel.c libavcodec/ppc/h264qpel_ppc.c || die popd >/dev/null || die fi Maybe this was only useful with the void linux patchset which the Gentoo ebuild used to carry.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6cd102d122ac1b27714ab3d5d3591dcbd087bfb commit f6cd102d122ac1b27714ab3d5d3591dcbd087bfb Author: Niccolò Belli <niccolo.belli@linuxsystems.it> AuthorDate: 2022-11-08 09:25:16 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2022-11-11 00:37:51 +0000 www-client/chromium: add ppc64le patchset from raptor engineering Closes: https://bugs.gentoo.org/669748 Acked-by: Mike Gilbert <floppym@gentoo.org> Signed-off-by: Niccolò Belli <niccolo.belli@linuxsystems.it> Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> www-client/chromium/Manifest | 2 + www-client/chromium/chromium-106.0.5249.119.ebuild | 55 +++++++++++++++++++++- www-client/chromium/chromium-107.0.5304.87.ebuild | 54 ++++++++++++++++++++- www-client/chromium/chromium-108.0.5343.2.ebuild | 52 ++++++++++++++++++++ .../files/ppc64le/fix-breakpad-compile.patch | 29 ++++++++++++ .../files/ppc64le/fix-swiftshader-compile.patch | 26 ++++++++++ .../files/ppc64le/libpng-pdfium-compile-98.patch | 13 +++++ 7 files changed, 229 insertions(+), 2 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5485188b30a11ce7d4dfaced60e408517a2945db commit 5485188b30a11ce7d4dfaced60e408517a2945db Author: Niccolò Belli <niccolo.belli@linuxsystems.it> AuthorDate: 2022-11-09 21:18:20 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2022-11-11 00:38:09 +0000 www-client/chromium: read patch series for ppc64 Bug: https://bugs.gentoo.org/669748 Closes: https://github.com/gentoo/gentoo/pull/28191 Acked-by: Mike Gilbert <floppym@gentoo.org> Signed-off-by: Niccolò Belli <niccolo.belli@linuxsystems.it> Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> www-client/chromium/chromium-106.0.5249.119.ebuild | 62 +++++----------------- www-client/chromium/chromium-107.0.5304.87.ebuild | 61 +++++---------------- www-client/chromium/chromium-108.0.5343.2.ebuild | 61 +++++---------------- 3 files changed, 36 insertions(+), 148 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=32372ea3298d68229cc954b5b5ce7d8a18dabbad commit 32372ea3298d68229cc954b5b5ce7d8a18dabbad Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2022-11-11 01:25:59 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2022-11-11 01:27:49 +0000 profiles/arch/powerpc/ppc64: force system-png for chromium ld.lld: error: undefined symbol: png_init_filter_functions_vsx Bug: https://bugs.gentoo.org/669748 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> profiles/arch/powerpc/ppc64/package.use.force | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
I've shed some light on the ./generate_gni.sh issue, but I'm unsure how to proceed: https://bugs.gentoo.org/882145
