dev-util/electron-28: patches needed for icu-74 and libxml2-2.12.5
joecool1029 opened this issue · comments
A dupe of #280, but I've needed this patch from that report for over a month: https://raw.githubusercontent.com/gentoo/gentoo/830d6ed5d3210ba88a668dabd2b0d0e446602ba2/dev-qt/qtwebengine/files/qtwebengine-6.5.3-icu74.patch
I also need this patch (the top 2 files) for building with libxml2-2.12.5: https://chromium-review.googlesource.com/c/chromium/src/+/4985186
EDIT: fixed URL typo on second link
Just checked, both my build chroots have libxml2-2.12.5, perhaps I've built electron-28 before updating libxml2, I'll try rebuilding electron with latest libxml2 and icu a bit later and update ebuild accordingly.
patches work to get v26 to compile for me as well.
patches work to get v26 to compile for me as well.
Why are you using electron-26 when even vscode switched to 27?
There was a reason I long since forgot. Propbably upgrade to v28 at some point.
I'm asking because I plan (actually for a long time already) to prune all electrons<27 now that vscode switched to 27.
Just upgraded to v28, works fine.
So. Is this the reason all of the electron ebuilds past 25 bail with unresolved symbols?
Yeah. This is why the OP is was still using an old version of Electron.
For what it's worth: in case anyone else is struggling with the link to the second set of patches returning 404 because they're tired of burning hours of compilation time and want it to stop, that's because it (somehow...?) contains an extra "i" in "chromium" as though someone had typed the URL out by hand.
This is the real URL. https://chromium-review.googlesource.com/c/chromium/src/+/4985186
Please mask the packages you haven't fully qualified as unstable.
So. Is this the reason all of the electron ebuilds past 25 bail with unresolved symbols?
Yeah.
@nethershaw Well, not entirely. Initially I wanted to write how I feel unfairly judged in your interpretation, being guilty for someone being "tired of burning hours of compilation time". But if you didn't notice that I was recently very busy elsewhere and only recently found some time to catch up with all the ebuilds in my overlay, it would not matter much to you.
Now that I'm blaimed for doing volunteer work (or rather not doing it for 2 months?) at my own expense I'm thinking whether I did the right decision to spend my recent time on advancing the overlay instead of doing just anything else… Feel discouraged to continue to be honest.
Yeah. This is why the OP
iswas still using an old version of Electron.
@nethershaw I was not using an old electron version. I build the current releases, when they fail I manually patch and continue the build from where it failed. (resume with ebuild /path/to/ebuild compile install qmerge).
For what it's worth: in case anyone else is struggling with the link to the second set of patches returning 404 because they're tired of burning hours of compilation time and want it to stop, that's because it (somehow...?) contains an extra "i" in "chromium" as though someone had typed the URL out by hand.
I probably hit a key on my keyboard by accident while submitting, I think most people would have figured it out. Either way it's updated now. It would have been helpful to just mention the URL was broken.
Please mask the packages you haven't fully qualified as unstable.
None of us have the CPU power to run CI on every single build configuration with a package as large as electron. I myself run the builds overnight and when they fail, I patch the errors in the morning and if I'm not that busy or it looks like it's been a thing for some time I file bugs like this. -system-icu users and users on stable arches wouldn't have hit either of these 2 build failures. AITA for not pointing to the patches sooner knowing it was broken or are you the one for not opening an issue to report the failure?
There's a reason this isn't in ::gentoo and a reason for overlays, if you use an overlay it's usually not going to match ::gentoo's QA standards since we do not have the time/resources, we can try but it's all best-effort. Complaining without contributing really demotivates maintainers from providing volunteer services, it's unwelcome.
For those using clang, you'll also need
--- cc/layers/mirror_layer_impl.h.old 2024-02-11 11:42:00.713435132 +1300
+++ cc/layers/mirror_layer_impl.h 2024-02-11 11:42:07.582482770 +1300
@@ -56,7 +56,8 @@
private:
const char* LayerTypeAsString() const override;
viz::CompositorRenderPassId mirrored_layer_render_pass_id() const {
- return viz::CompositorRenderPassId{mirrored_layer_id()};
+ return viz::CompositorRenderPassId{
+ static_cast<uint64_t>(mirrored_layer_id())};
}
int mirrored_layer_id_ = 0;
I'll update if there's more.
For those using clang, you'll also need
I'm building with clang-17.0.6 and haven't hit a failure. Is this issue limited to clang-18?
Here's upstream review: https://chromium-review.googlesource.com/c/chromium/src/+/5150303
For those using clang, you'll also need
I'm building with clang-17.0.6 and haven't hit a failure. Is this issue limited to clang-18?
Yeah, for >=clang-18.
I'm using the old clang18-narrowing.patch from this repo as well as the 3 you mentioned.
You can add a tilde to your keywords while you're working on an ebuild; you can remove it when you're done. I can't contribute that for you -- you alone know what you are working on. Don't moralize at me.
@JohnFlowerful Have you had any other issues? My build had finished and no more issues it seems.
clang-18 ran into llvm/llvm-project#80210 when building pdfium.
I switched back to clang-17 with the mentioned patches and it went fine.
I'll try the fixed ebuild today at some stage.
Had a fiddle with the above issue. Turns out Gentoo's >=clang-18 packages have the debug useflag enabled. Disabling that got me passed it.