https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: sci-electronics/kicad-7.0.6 fails to compile. Discovered on: amd64 (internal ref: ci)
Created attachment 866051 [details] build.log.xz build log and emerge --info (compressed because it exceeds attachment limit, use 'xzless' to read it)
Error(s) that match a know pattern in addition to what has been reported in the summary: FAILED: common/gal/CMakeFiles/gal.dir/__/draw_panel_gal.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/antialiasing.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/cached_container.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/cached_container_gpu.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/cached_container_ram.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/gpu_manager.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/noncached_container.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/opengl_compositor.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/opengl_gal.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/shader.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/utils.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/vertex_container.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/vertex_item.cpp.o FAILED: common/gal/CMakeFiles/gal.dir/opengl/vertex_manager.cpp.o /var/tmp/portage/sci-electronics/kicad-7.0.6/work/kicad-7.0.6/include/gal/opengl/kiglew.h:47:14: error: #error "KICAD_USE_EGL can only be used when wxWidgets is compiled with the EGL canvas"
Manifested with: commit ba4d88bfb4f7bff4d69a0b0d6d06035cb1bcdd76 Author: Piotr Karbowski <slashbeast@gentoo.org> Date: Sun Jul 23 18:22:29 2023 +0200 x11-libs/wxGTK: 3.2.2.1-r3: Switch to wxGLCanvas GLX. Explicitly disabling glcanvasegl: https://github.com/gentoo/gentoo/blob/568b05e64aaeb061f7acd7647185a07c199e054c/x11-libs/wxGTK/wxGTK-3.2.2.1-r3.ebuild#L149-L150 conflicts with kicad which needs wxGTK to be built with EGL: https://github.com/gentoo/gentoo/blob/master/sci-electronics/kicad/kicad-7.0.6.ebuild#L104 Which started to be the case in February: commit e2727746cd7823177e43b15f01314e60d68397a6 Author: Matthew Smith <matthew@gentoo.org> Date: Sat Feb 18 10:41:05 2023 +0000 sci-electronics/kicad: Use wxGTK-3.2 wxGTK is slotted and wxpython is not. The versions must match, so use the latest version for now. Unfortunately the commit message does not mention why is there a need to switch to EGL backend.
This bug report is wxWidgets adjacent, and a bit old, so it may not be accurate, but it appears to imply that EGL is required for Wayland (although EGL can also use X11). GLX appears to be X11 only. https://github.com/wxWidgets/Phoenix/issues/1923 So that may be a reason why EGL was enabled for a time. From the above issue report, it looks like wxWidgets doesn't yet support runtime selection of the backend, which seems to be the true root of the issue here-- it can't fall back on its own.
As I use wayland at home, I modified wxGTK's ebuild to enable the EGL backend, and I was successful at building both it and kicad. Is the answer here exposing a wayland flag in wxGTK to enable EGL?
Looks like 7.0.6 and at least 7.0.2 (probably all versions) won't compile or run (if you update wxTGK, an existing kicad install will crash when trying to start eeschema or pcbnew) with wxGTK-3.2.2.1-r3. Maybe add a block on that wxGTK version to the kicad ebuilds until it's fixed?
I confirm downgrading wxGTK to =x11-libs/wxGTK-3.2.2.1-r2 lead to a successful kicad merge.
(In reply to Gabriel Marcano from comment #4) > This bug report is wxWidgets adjacent, and a bit old, so it may not be > accurate, but it appears to imply that EGL is required for Wayland (although > EGL can also use X11). GLX appears to be X11 only. > > https://github.com/wxWidgets/Phoenix/issues/1923 > > So that may be a reason why EGL was enabled for a time. From the above issue > report, it looks like wxWidgets doesn't yet support runtime selection of the > backend, which seems to be the true root of the issue here-- it can't fall > back on its own. (In reply to Gabriel Marcano from comment #5) > As I use wayland at home, I modified wxGTK's ebuild to enable the EGL > backend, and I was successful at building both it and kicad. > > Is the answer here exposing a wayland flag in wxGTK to enable EGL? wxGTK and kicad should get that USE flag. kicad should then depend mutually exclusive on that USE flag in wxGTK whether enabled or disabled. kicad ebuild (untested draft,ngspice USE flag will go away Bug 910550 ): IUSE="doc examples +ngspice nls openmp wayland" wayland? (x11-libs/wxGTK:${WX_GTK_VER}[X,opengl,wayland]) !wayland? (x11-libs/wxGTK:${WX_GTK_VER}[X,opengl,!wayland]) -DKICAD_USE_EGL="$(usex wayland)" Does dev-python/wxpython need a rebuild after switching egl glx in wxGTK?
(In reply to jospezial from comment #8) > wxGTK and kicad should get that USE flag. > kicad should then depend mutually exclusive on that USE flag in wxGTK whether > enabled or disabled. > > kicad ebuild (untested draft,ngspice USE flag will go away Bug 910550 ): > > IUSE="doc examples +ngspice nls openmp wayland" > > wayland? (x11-libs/wxGTK:${WX_GTK_VER}[X,opengl,wayland]) > !wayland? (x11-libs/wxGTK:${WX_GTK_VER}[X,opengl,!wayland]) > > -DKICAD_USE_EGL="$(usex wayland)" > I'm not sure this is a good path forward. The wayland USE flag seems to be enabled from the desktop profile (at least for me on default/linux/amd64/17.1/desktop/plasma/systemd), which means we would still default to a failing build. > > Does dev-python/wxpython need a rebuild after switching egl glx in wxGTK? It seems to me there is no need to rebuild dev-python/wxpython, only x11-libs/wxGTK, at least based on my tests KiCad will not crash. There are multiple paths that can be taken: 1. restrict wxGTK dependency to <3.2.2.1-r2 2. make sci-electronics/kicad unconditionally depend on x11-libs/wxGTK being built with -wayland USE flag 3. disable KICAD_USE_EGL I don't like the first option since it just kicking the can down the road and IMHO preventing users from upgrade is bad practice. The second and third options could potentially break Wayland users, though disabling KICAD_USE_EGL allows KiCad to build with x11-libs/wxGTK[wayland] and it also works properly under xorg. As per KiCad build documentation[1]: "KICAD_USE_EGL Build KiCad with EGL backend support for Wayland." I haven't gotten to test yet, whether KiCad with KICAD_USE_EGL disabled works under Wayland or not. If it does, I'll go with the third option, if not then I'm not sure yet how to fix this properly. [1] https://dev-docs.kicad.org/en/build/compile-options/
I think disabling EGL will work just fine, Fedora did the same thing with wxWidgets EGL and if you take look at how they do kicad[1] they also disable EGL on it. [1] https://src.fedoraproject.org/rpms/kicad/blob/rawhide/f/kicad.spec
> I haven't gotten to test yet, whether KiCad with KICAD_USE_EGL disabled > works under Wayland or not. If it does, I'll go with the third option, if > not then I'm not sure yet how to fix this properly. I just tested kicad-9999.ebuild with -DKICAD_USE_EGL=OFF and x11-libs/wxGTK-3.2.2.1-r3 on plasma wayland. I can't see any problems.
Thanks for testing it with Wayland! Turning off KICAD_USE_EGL.
> > I haven't gotten to test yet, whether KiCad with KICAD_USE_EGL disabled > > works under Wayland or not. If it does, I'll go with the third option, if > > not then I'm not sure yet how to fix this properly. > > I just tested kicad-9999.ebuild with -DKICAD_USE_EGL=OFF and > x11-libs/wxGTK-3.2.2.1-r3 on plasma wayland. > I can't see any problems. (In reply to Zoltan Puskas from comment #12) > Thanks for testing it with Wayland! Turning off KICAD_USE_EGL. I think that only works because kwin uses xwayland with mesa there to provide GL. Beside that, x11-libs/wxGTK also has a opengl USE. Can somebody, who has a wayland based desktop environment without dependency to xwayland, test kicad ebuild with -DKICAD_USE_EGL=OFF and x11-libs/wxGTK-3.2.2.1-r3 ? What do people who use gentoo on a graphics chip that does not provide (open)gl or glx? I have seen it is possible to disable acceleration in kicad settings. It is not easy to understand that whole stuff. GL names and dependencies.
(In reply to Martin Kletzander from comment #3) > Manifested with: > > commit ba4d88bfb4f7bff4d69a0b0d6d06035cb1bcdd76 > Author: Piotr Karbowski <slashbeast@gentoo.org> > Date: Sun Jul 23 18:22:29 2023 +0200 > > x11-libs/wxGTK: 3.2.2.1-r3: Switch to wxGLCanvas GLX. > This commit should've had some detail as to why we're doing this? slashbeast?
He needed it for prusaslicer in relation to https://github.com/prusa3d/PrusaSlicer/issues/9774 Why that issue is closed now, I don't know - prusaslicer ought to be working towards being compatible with EGL. But there's hopefully a more specific issue or something for that, as that one was a specific crash report. As Fedora builds it as such, I gave an ACK to just unconditionally disable it, without knowing it would affect anything else, so we might need to revisit it. To me, kicad has a higher importance, and it's a regression to kicad, so the natural thing would be to revert the wxGTK change for now, unless a viable solution is near. Forcing Kicad to run with xwayland (if that's what it does then with EGL disabled) isn't what I would consider a viable solution - however it might be a short-term solution if prusaslicer will work with EGL in the near future. Does it force xwayland and start kicad seamlessly in xwayland when built without EGL or one would need to even manually influence it with GDK_BACKEND or similar? One way to confirm if something is using X11 or Wayland is to run x11-apps/xdpyinfo and click on a kicad window - if it returns information about kicad to the terminal, it's using Xwayland (assuming the desktop is on wayland), if it's returning something else (something below it, or your compositors root guard X window), then it's using wayland and xdpyinfo doesn't see it.
I've just tried it by starting a Wayland session, running KiCad and then using `xlsclients` to list xwayland clients. KiCad indeed does run under xwayland when EGL is off. This might be suboptimal for Wayland users, but I think it still better that none of the KiCad versions building. I'd prefer if the current PR was merged for now and later we can re-enable EGL once the wxGTK issue is resolved.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e3371a44d2e12d79c8177d58bc7ec4d0ba3b5cc9 commit e3371a44d2e12d79c8177d58bc7ec4d0ba3b5cc9 Author: Zoltan Puskas <zoltan@sinustrom.info> AuthorDate: 2023-08-04 05:45:54 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-08-09 05:11:10 +0000 sci-electronics/kicad: Fix build failure with GLX enabled wxGTK Closes: https://bugs.gentoo.org/911120 Signed-off-by: Zoltan Puskas <zoltan@sinustrom.info> Closes: https://github.com/gentoo/gentoo/pull/32055 Signed-off-by: Sam James <sam@gentoo.org> sci-electronics/kicad/{kicad-7.0.1.ebuild => kicad-7.0.1-r1.ebuild} | 5 ++++- sci-electronics/kicad/{kicad-7.0.2.ebuild => kicad-7.0.2-r1.ebuild} | 5 ++++- .../kicad/{kicad-7.0.6-r1.ebuild => kicad-7.0.6-r2.ebuild} | 5 ++++- sci-electronics/kicad/kicad-9999.ebuild | 5 ++++- 4 files changed, 16 insertions(+), 4 deletions(-)
(In reply to Sam James from comment #14) > (In reply to Martin Kletzander from comment #3) > > Manifested with: > > > > commit ba4d88bfb4f7bff4d69a0b0d6d06035cb1bcdd76 > > Author: Piotr Karbowski <slashbeast@gentoo.org> > > Date: Sun Jul 23 18:22:29 2023 +0200 > > > > x11-libs/wxGTK: 3.2.2.1-r3: Switch to wxGLCanvas GLX. > > > > This commit should've had some detail as to why we're doing this? > > slashbeast? This has been extensively discussed with Leio, the maintainer of wxGTK. After checking how others do we collectively decided to follow Fedora example and disable EGL GLCanvas as they as well were facing issues with the EGL implementation.
(In reply to Mart Raudsepp from comment #15) > He needed it for prusaslicer in relation to > https://github.com/prusa3d/PrusaSlicer/issues/9774 > Why that issue is closed now, I don't know - prusaslicer ought to be working > towards being compatible with EGL. But there's hopefully a more specific > issue or something for that, as that one was a specific crash report. > > As Fedora builds it as such, I gave an ACK to just unconditionally disable > it, without knowing it would affect anything else, so we might need to > revisit it. To me, kicad has a higher importance, and it's a regression to > kicad, so the natural thing would be to revert the wxGTK change for now, > unless a viable solution is near. > > Forcing Kicad to run with xwayland (if that's what it does then with EGL > disabled) isn't what I would consider a viable solution - however it might > be a short-term solution if prusaslicer will work with EGL in the near > future. > Does it force xwayland and start kicad seamlessly in xwayland when built > without EGL or one would need to even manually influence it with GDK_BACKEND > or similar? > > One way to confirm if something is using X11 or Wayland is to run > x11-apps/xdpyinfo and click on a kicad window - if it returns information > about kicad to the terminal, it's using Xwayland (assuming the desktop is on > wayland), if it's returning something else (something below it, or your > compositors root guard X window), then it's using wayland and xdpyinfo > doesn't see it. I do not believe they will ever focus on the EGL support given how old and difficult the slic3r codebase is. If you do not consider it kicad using xwayland when wxGTK lacks EGL a viable solution then feel free to revert the wxGTK changes and I will start working on building wxGTK as part of vendorized dependency for prusa-slicer and link it statically.
(In reply to Piotr Karbowski from comment #18) > (In reply to Sam James from comment #14) > > (In reply to Martin Kletzander from comment #3) > > > Manifested with: > > > > > > commit ba4d88bfb4f7bff4d69a0b0d6d06035cb1bcdd76 > > > Author: Piotr Karbowski <slashbeast@gentoo.org> > > > Date: Sun Jul 23 18:22:29 2023 +0200 > > > > > > x11-libs/wxGTK: 3.2.2.1-r3: Switch to wxGLCanvas GLX. > > > > > > > This commit should've had some detail as to why we're doing this? > > > > slashbeast? > > This has been extensively discussed with Leio, the maintainer of wxGTK. I'm not saying you didn't discuss it with him, I'm saying that it should've been reflected in the commit message. Commit messages are forever and they're really useful for looking up why a change happened.
x11-libs/wxGTK-3.2.2.1-r3 is not marked stable yet. As you have already marked this change (sci-electronics/kicad-7.0.1-r1) stable it breaks a stable systems. error: #error "KICAD_USE_EGL must be defined since wxWidgets has been compiled with the EGL canvas"
I've not thought of that, as I was testing the ebuilds with x11-libs/wxGTK-3.2.2.1-r3. Let me submit a PR for another revision to revert the EGL flag for stable, but I'll also limit the wxGTK version to avoid breakage later.
I'm good with making Kicad run under Xwayland for a period of time too, so we can keep prusaslicer working for now. Maybe there is an approach where wxWidgets would grow support for either option for GLCanvas to work from the same build? Anyone found any wxWidgets tickets to that effect, which might say that it's not possible technically or no-one working on it, or anything?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4711b0ec2776941c3dbc2e23a28fb4fae4197e36 commit 4711b0ec2776941c3dbc2e23a28fb4fae4197e36 Author: Zoltan Puskas <zoltan@sinustrom.info> AuthorDate: 2023-08-10 04:24:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-08-10 04:45:53 +0000 sci-electronics/kicad: Revert EGL flag for stable In stable wxGTK is still built with EGL instead of GLX, so build KiCAD with EGL enabled, but also limit the wxGTK version to prevent build failures, in case GLX enabled wxGTK goes stable or the user unmasks it. Since users cannot upgrade to -r1 due to build failures, it's better to revert to no revision version. This should prevent unnecessary rebuilds for anyone who has KiCad already installed. Bug: https://bugs.gentoo.org/911120 Signed-off-by: Zoltan Puskas <zoltan@sinustrom.info> Closes: https://github.com/gentoo/gentoo/pull/32240 Signed-off-by: Sam James <sam@gentoo.org> .../kicad/{kicad-7.0.1-r1.ebuild => kicad-7.0.1.ebuild} | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
(In reply to Jesper Saxtorph from comment #21) > x11-libs/wxGTK-3.2.2.1-r3 is not marked stable yet. > As you have already marked this change (sci-electronics/kicad-7.0.1-r1) > stable it breaks a stable systems. > > error: #error "KICAD_USE_EGL must be defined since wxWidgets has been > compiled with the EGL canvas" I agree, with this change kicad does not compile on my systems as well. Why is KICAD_USE_EGL set to NO? There is already the egl use flag (used by qtgui, mpv and others), please change the "fix" to -DKICAD_USE_EGL="$(usex egl)" This way everyone can adapt it for his setup, it is not tied to wayland and this works right out of the box for me.
*** Bug 912460 has been marked as a duplicate of this bug. ***
I'm reopening this issue, since it's not resolved for all combination of builds and the forced EGL flag is causing issues. Since KiCad 7.0.7 has been released I'll resolve this issue in the coming days by updating the ebuild during bump and adding an egl flag as suggested by Konstantin Münning. I think probably some dependency version restrictions are also in order.
I don't think IUSE=egl on kicad makes sense for this really with how it changes what wxGTK versions it depends on. That's not a good approach for the ebuild, and not something we want to see put into the main tree as wxGTK maintainers, because this is effectively blocking the removal of x11-libs/wxGTK-3.2.2.1-r2 and older from regular "remove old" tree cleanup.
Coming from #912460 installed version(s) of wxGtk are: $> qlist -IRv x11-libs/wxGTK x11-libs/wxGTK-3.2.2.1-r2::gentoo x11-libs/wxGTK-3.0.5.1-r1::gentoo
(In reply to Mart Raudsepp from comment #28) > I don't think IUSE=egl on kicad makes sense for this really with how it > changes what wxGTK versions it depends on. That's not a good approach for > the ebuild, and not something we want to see put into the main tree as wxGTK > maintainers, because this is effectively blocking the removal of > x11-libs/wxGTK-3.2.2.1-r2 and older from regular "remove old" tree cleanup. Since wxGTK switches GLX implementations it means that some form of version restrictions still need to be imposed, even if not dependant on a USE flag, otherwise certain builds will fail. We have quite a few use cases that we'd like to serve, namely: - users might be on stable, unmasking testing KiCad to get the latest version, but that now would also mean pulling in a testing wxGTK that is built with GLX if we permanently disable EGL in KiCad - users might be on testing, but pre `-r3` version of wxGTK, in which case KiCad needs to built with EGL - users might be using Wayland, in which case using EGL is preferred to avoid relying Xwayland (AFAIK X.org users can go with either EGL or GLX version of wxGTK and KiCad as long as the latter two are in sync) - rebuilding KiCad is expensive, so we'd like to minimize that - Plasma and GNOME desktop profile users have IUSE="opengl wayland" enabled from the profile, regardless which display server they use, so we cannot rely on these flags to make build decisions. This is why I introduced the IUSE="egl" flag, to give the users some control. I'm open to suggestions on what's the best way to resolve this with the least amount of frustration to users.
The bug persists in =sci-electronics/kicad-7.0.6-r2
(In reply to Michał Dec from comment #31) > The bug persists in =sci-electronics/kicad-7.0.6-r2 And in =sci-electronics/kicad-7.0.2-r1
*** Bug 914462 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=20c2df020d62adfe6cc523773e1098c82e54c16e commit 20c2df020d62adfe6cc523773e1098c82e54c16e Author: Rafael Kitover <rkitover@gmail.com> AuthorDate: 2023-09-20 18:53:07 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-09-22 14:54:05 +0000 x11-libs/wxGTK: explain reason for disabling EGL Explain the rationale for disabling the EGL wxGLCanvas in the ebuild comments. Bug: https://bugs.gentoo.org/833443 Bug: https://bugs.gentoo.org/911120 Signed-off-by: Rafael Kitover <rkitover@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/32452 Signed-off-by: Sam James <sam@gentoo.org> x11-libs/wxGTK/wxGTK-3.2.2.1-r3.ebuild | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
Please add to "See Also": https://github.com/wxWidgets/wxWidgets/issues/22325 "Add run-time check for EGL version on canvas creation" Active discussion how to solve this in wxWidgets. Maybe the PR entries can be cleaned up.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0c21128b45c84f2145bda679c842317d9b3b4423 commit 0c21128b45c84f2145bda679c842317d9b3b4423 Author: Zoltan Puskas <zoltan@sinustrom.info> AuthorDate: 2023-08-25 05:08:13 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-09-23 09:50:03 +0000 sci-electronics/kicad: add 7.0.7 Closes: https://bugs.gentoo.org/911120 Signed-off-by: Zoltan Puskas <zoltan@sinustrom.info> Signed-off-by: Sam James <sam@gentoo.org> sci-electronics/kicad/Manifest | 1 + sci-electronics/kicad/kicad-7.0.7.ebuild | 167 +++++++++++++++++++++++++++++++ 2 files changed, 168 insertions(+)
