https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: sci-electronics/kicad-8.0.1 fails to compile. Discovered on: amd64 (internal ref: ci) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0014
Created attachment 888761 [details] build.log build log and emerge --info
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f1cce39266c87dd148a87b8deda5001e24a4e1c1 commit f1cce39266c87dd148a87b8deda5001e24a4e1c1 Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2024-05-03 12:46:22 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2024-05-03 12:51:08 +0000 sci-electronics/kicad: add 8.0.2 - compat with occt 8.0.2 - fix finding libs in tests - filter-lto - add missing dep on wxGTK[wayland] - drop USE=telemetry, this now requires configureing DSN at build time, upstream default is off, other distro's do not enable this, unclear what the DSN should be if enabled. Closes: https://bugs.gentoo.org/923351 Closes: https://bugs.gentoo.org/927226 Closes: https://bugs.gentoo.org/927482 Closes: https://bugs.gentoo.org/927952 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> sci-electronics/kicad/Manifest | 1 + sci-electronics/kicad/kicad-8.0.2.ebuild | 180 +++++++++++++++++++++++++++++++ sci-electronics/kicad/kicad-9999.ebuild | 16 +-- 3 files changed, 191 insertions(+), 6 deletions(-)
> - add missing dep on wxGTK[wayland] I'm sorry but I don't think this is the right solution. Forcing users to pull in Wayland to fix an LTO problem doesn't feel right to me. Especially as on a (non LTO) system where -wayland is set globally, Kicad builds perfectly fine if the dependency is >=x11-libs/wxGTK-3.2.2.1-r3:${WX_GTK_VER}[X,opengl]. Perhaps x11-libs/gtk+[wayland] should force x11-libs/wxGTK[wayland] but that's a pure guess and how to express that is way outside my ebuild-fu.
(In reply to Frej Drejhammar from comment #3) > > - add missing dep on wxGTK[wayland] > > I'm sorry but I don't think this is the right solution. Forcing users to > pull in Wayland to fix an LTO problem doesn't feel right to me. Especially > as on a (non LTO) system where -wayland is set globally, Kicad builds > perfectly fine if the dependency is > >=x11-libs/wxGTK-3.2.2.1-r3:${WX_GTK_VER}[X,opengl]. > > Perhaps x11-libs/gtk+[wayland] should force x11-libs/wxGTK[wayland] but > that's a pure guess and how to express that is way outside my ebuild-fu. Sorry I'm having a confused day :) It's not an LTO problem, just an ordinary linking issue. But my point of needlessly pulling in Wayland for something that is an issue between Gtk and wxGTK still holds.
kicad-8.0.1 built fine for me without wayland, and now i have to rebuild both gtk+ and wxGTK and whatnot with USE=wayland to build 8.0.2 :/
``` Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python3.11/site-packages/wx/__init__.py", line 17, in <module> from wx.core import * File "/usr/lib/python3.11/site-packages/wx/core.py", line 12, in <module> from ._core import * ImportError: /usr/lib64/libwx_gtk3u_core-3.2-gtk3.so.0: undefined symbol: gdk_wayland_display_get_wl_display ``` This looks like the usual gtk automagic with wayland. wxgtk needs to gain wayland= instead for its dep on gtk+, I think. Anyway, I agree, I think the dep change in kicad isn't right here - the fix needs to either be in wxgtk, or in gtk.
(In reply to Frej Drejhammar from comment #3) > > - add missing dep on wxGTK[wayland] > > I'm sorry but I don't think this is the right solution. Forcing users to > pull in Wayland to fix an LTO problem doesn't feel right to me. These are two seperate things, this bug is not an LTO bug
(In reply to Sam James from comment #6) > This looks like the usual gtk automagic with wayland. wxgtk needs to gain > wayland= instead for its dep on gtk+, I think. > > Anyway, I agree, I think the dep change in kicad isn't right here - the fix > needs to either be in wxgtk, or in gtk. I will revert that in a bit. Do we have the same weird automagic stuff going on for the X flag? Should that USE dependency also be removed?
AFAIK the only gtk automagic is in sysprof and wayland
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=806860100b5613f837046ed2789da5b2ffaf51bb commit 806860100b5613f837046ed2789da5b2ffaf51bb Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2024-05-04 16:52:30 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2024-05-04 16:52:30 +0000 sci-electronics/kicad: drop dep on wayland Bug: https://bugs.gentoo.org/927952 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> sci-electronics/kicad/{kicad-8.0.2.ebuild => kicad-8.0.2-r1.ebuild} | 2 +- sci-electronics/kicad/kicad-9999.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
For what's worth, I had veracrypt fail to run and to rebuild after I had made a system upgrade and changed from USE=wayland to USE=-wayland (yep, mid upgrade, so my bad I guess) $ veracrypt veracrypt: symbol lookup error: /usr/lib64/libwx_gtk3u_core-3.2-gtk3.so.0: undefined symbol: gdk_wayland_display_get_wl_display rebuild: ... /usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libwx_gtk3u_core-3.2-gtk3.so: undefined reference to `gdk_wayland_display_prefers_ssd' /usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libwx_gtk3u_core-3.2-gtk3.so: undefined reference to `gdk_wayland_display_get_wl_display' collect2: error: ld returned 1 exit status make[1]: *** [Main.make:162: veracrypt] Error 1 ... But the fix was to just rebuild x11-libs/wxGTK-3.2.2.1-r4:3.2-gtk3::gentoo and then rebuild app-crypt/veracrypt-1.26.7 (although maybe the latter rebuild wasn't needed, unsure). @preserved-rebuild or anything about world upgrades didn't detect the need for this wxGTK rebuild, so that was kinda odd, i dno. ie. the system seemed consistent, and the only gtk(3) app that I had was veracrypt. Everything else in the system working ok. I guess rebuilding everything just to be sure would be in order, at this point.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=efaf2366cea9a37456b75eaa2081e7339edd38ea commit efaf2366cea9a37456b75eaa2081e7339edd38ea Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-05-05 20:51:41 +0000 Commit: Eli Schwartz <eschwartz@gentoo.org> CommitDate: 2024-08-06 00:18:29 +0000 x11-libs/wxGTK: prevent automagically building against gtk[X,wayland] The upstream code checks whether GDK_WINDOWING_WAYLAND is defined by the gtk headers, and if so will compile against the wayland symbols it provides. This despite that wxGTK has a wayland USE flag, and checks it in the build system -- just not for this. This means that when built on a system with gtk+[-wayland] will be compatible with anything, but when built on a system with gtk+[wayland], requires that at runtime regardless of USE flag. This cannot be expressed with USE flags. We could bind tightly to whether gtk was built with wayland and arbitrarily restrict wxGTK[-wayland] to only build and install on a system with gtk+[-wayland]. But we recently added a hack to gtk itself which allows hiding the automagic macros entirely. Inject this via append-cflags if the USE flags aren't set, to simulate building on a system with more minimal gtk packages. Bug: https://bugs.gentoo.org/624960 Closes: https://bugs.gentoo.org/927952 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> x11-libs/wxGTK/wxGTK-3.2.2.1-r5.ebuild | 262 +++++++++++++++++++++++++++++++++ 1 file changed, 262 insertions(+)
