Call Stack (most recent call first): /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:598 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake/Modules/FindwxWidgets.cmake:1014 (find_package_handle_standard_args) CMakeLists.txt:30 (find_package) -- Configuring incomplete, errors occurred! * ERROR: app-text/crwx-ng-0.3.1-r1::gentoo failed (configure phase): * cmake failed ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_no_multilib-20240613-224309 UNMASKED: ~dev-libs/icu-75.1 ~dev-libs/icu-layoutex-75.1 ~dev-lang/perl-5.40.0 ~virtual/perl-Archive-Tar-3.20.10_rc ~virtual/perl-CPAN-Meta-Requirements-2.143.0 ~virtual/perl-Compress-Raw-Bzip2-2.212.0 ~virtual/perl-DB_File-1.859.0 ~virtual/perl-Data-Dumper-2.189.0 ~virtual/perl-Devel-PPPort-3.720.0 ~virtual/perl-Exporter-5.780.0 ~virtual/perl-ExtUtils-CBuilder-0.280.240 ~virtual/perl-ExtUtils-Manifest-1.750.0 ~virtual/perl-File-Spec-3.900.0 ~virtual/perl-HTTP-Tiny-0.88.0 ~virtual/perl-IO-1.550.0 ~virtual/perl-IO-Compress-2.212.0 ~virtual/perl-IO-Socket-IP-0.420.0 ~virtual/perl-IO-Zlib-1.150.0 ~virtual/perl-Math-BigInt-2.3.2 ~virtual/perl-Math-BigInt-FastCalc-0.501.800 ~virtual/perl-Math-BigRat-2.3.2 ~virtual/perl-Module-CoreList-5.202.406.90 ~virtual/perl-Module-Metadata-1.0.38 ~virtual/perl-Pod-Simple-3.450.0 ~virtual/perl-Safe-2.460.0 ~virtual/perl-Socket-2.38.0 ~virtual/perl-Test-Harness-3.480.0 ~virtual/perl-Test-Simple-1.302.199 ~virtual/perl-Text-Tabs+Wrap-2024.1.0 ~virtual/perl-Time-HiRes-1.977.700 ~virtual/perl-Time-Local-1.350.0 ~virtual/perl-autodie-2.370.0 ~virtual/perl-bignum-0.670.0 ~virtual/perl-podlators-5.10.200_rc ~virtual/perl-threads-2.400.0 ~virtual/perl-threads-shared-1.690.0 ~virtual/perl-version-0.993.0 The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-10 [2] x86_64-pc-linux-gnu-14 * clang/llvm (if any): clang version 18.1.7 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/18/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/18 18.1.7 Python 3.12.4 Available Ruby profiles: [1] ruby31 (with Rubygems) [2] ruby32 (with Rubygems) [3] ruby33 (with Rubygems) * Available Rust versions: [1] rust-bin-1.78.0 * The following VMs are available for generation-2: 1) OpenJDK 17.0.11_p9 [openjdk-17] 2) Eclipse Temurin JDK 17.0.11_p9 [openjdk-bin-17] *) Eclipse Temurin JDK 21.0.3_p9 [openjdk-bin-21] 4) Eclipse Temurin JDK 8.412_p08 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-17 [2] openjdk-bin-8 [3] openjdk-bin-17 [4] openjdk-bin-21 system-vm The Glorious Glasgow Haskell Compilation System, version 9.2.8 php cli (if any): go version go1.22.4 linux/amd64 HEAD of ::gentoo commit 8a73232f2111f1cf05b12b4e087afdd7f16d5f89 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Wed Jun 19 04:49:39 2024 +0000 2024-06-19 04:49:38 UTC emerge -qpvO app-text/crwx-ng [ebuild N ] app-text/crwx-ng-0.3.1-r1 USE="chm fribidi harfbuzz libunibreak libutf8proc svg zstd -gif"
Created attachment 896079 [details] emerge-info.txt
Created attachment 896080 [details] app-text:crwx-ng-0.3.1-r1:20240619-091618.log
Created attachment 896081 [details] emerge-history.txt.xz
Created attachment 896082 [details] environment
Created attachment 896083 [details] etc.clang.tar.xz
Created attachment 896084 [details] etc.portage.tar.xz
Created attachment 896085 [details] qlist-info.txt.xz
Created attachment 896086 [details] temp.tar.xz
--- crwx-ng-0.3.1-r1.ebuild 2024-06-20 08:20:37.191473961 +0400 +++ crwx-ng-0.3.1-r2.ebuild 2024-06-20 08:23:02.569865117 +0400 @@ -20,6 +20,7 @@ RDEPEND="${CDEPEND} virtual/ttf-fonts" -pkg_prepare() { +src_configure() { setup-wxwidgets + cmake_src_configure }
Sorry, I cannot understand what's happening here (and hence I don't know if the proposed fix fixed the problem). The relevant pieces of crwx-ng-0.3.1-r1.ebuild are WX_GTK_VER="3.2-gtk3" inherit wxwidgets BDEPEND="x11-libs/wxGTK:${WX_GTK_VER}[X]" pkg_prepare() { setup-wxwidgets } Here BDEPEND requires that x11-libs/wxGTK:3.2-gtk3[X] is installed on the computer which emerges this ebuild. However, the build log contains Could NOT find wxWidgets: Found unsuitable version "3.0.5", but required is at least "3.2" (found -L/usr/lib64;-pthread;;;-lwx_baseu-3.0-gtk3;-lwx_gtk3u_core-3.0-gtk3;-lwx_gtk3u_html-3.0-gtk3) How can this happen?? On my system the corresponding line is Found wxWidgets: -L/usr/lib64;-pthread;;;-lwx_baseu-3.2-gtk3;-lwx_gtk3u_core-3.2-gtk3;-lwx_gtk3u_html-3.2-gtk3 (found suitable version "3.2.2", minimum required is "3.2") And this must happen always, because of BDEPEND (3.0.5 is not in the slot 3.2-gtk3, whether it is present or absent is irrelevant, but something from the slot 3.2-gtk3 must be installed). I've checked a few ebuilds inheriting wxwidgets. They mostly look the same: WX_GTK_VER="3.2-gtk3" inherit wxwidgets DEPEND="x11-libs/wxGTK:${WX_GTK_VER}[X]" pkg_prepare() { setup-wxwidgets } setup-wxwidgets is called from pkg_prepare (though media-sound/audacity ebuilds call it from src_configure). What's the right thing to do - to call it from pkg_prepare (as most ebuilds do) or from src_configure (as audacity)? Maybe, x11-libs/wxGTK:${WX_GTK_VER} should be in DEPEND, not BDEPEND? I was never able to understand the difference between DEPEND and BDEPEND (probably, becase I never did cross-compilation).
Most likely this happens when two versions of wxGTK are installed on the system: 3.0.5 and 3.2.2, but version 3.0.5 is selected ( eselect wxwidgets list ). For this case, use the setup-wxwidgets() function and calling it in src_prepare() previously worked. But it seems that something has changed in portage, in <portage>/eclass/wxwidgets.eclass it is written that the setup-wxwidgets() function should be called in src_configure(). It works this way.
(In reply to Aleksey Chernov from comment #11) > Most likely this happens when two versions of wxGTK are installed on the > system: 3.0.5 and 3.2.2, but version 3.0.5 is selected ( eselect wxwidgets > list ). > > For this case, use the setup-wxwidgets() function and calling it in > src_prepare() previously worked. > > But it seems that something has changed in portage, in > <portage>/eclass/wxwidgets.eclass it is written that the setup-wxwidgets() > function should be called in src_configure(). > > It works this way. OK, Alexey, then I'll commit your fix. I cannot test it, because I have 3.2 only, no 3.0: bilbo ~ # eselect wxwidgets list Available wxWidgets profiles: [1] gtk3-unicode-3.2-gtk3 * Should all the other ebuilds in the tree inheriting wxwidgets be updated similarly? (i.e., call setup-wxwidgets not from pkg_prepare but from src_configure). There are maaaany of them. I am especially interested about sci-mathematics/wxmaxima which I maintain. It is currently written in the more standard way: WX_GTK_VER="3.2-gtk3" inherit wxwidgets DEPEND="x11-libs/wxGTK:${WX_GTK_VER}[X]" pkg_prepare() { setup-wxwidgets } Can somebody who has both 3.0-gtk3 and 3.2-gtk3 installed and 3.0-gtk3 eselected check if wxmaxima emerges successfully? (I haven't got such bug reports about it, and on my system, with 3.2-gtk3, it, of course, emerges fine.)
(In reply to Andrey Grozin from comment #12) > (In reply to Aleksey Chernov from comment #11) > > Most likely this happens when two versions of wxGTK are installed on the > > system: 3.0.5 and 3.2.2, but version 3.0.5 is selected ( eselect wxwidgets > > list ). > > > > For this case, use the setup-wxwidgets() function and calling it in > > src_prepare() previously worked. > > > > But it seems that something has changed in portage, in > > <portage>/eclass/wxwidgets.eclass it is written that the setup-wxwidgets() > > function should be called in src_configure(). > > > > It works this way. > OK, Alexey, then I'll commit your fix. I cannot test it, because I have 3.2 > only, no 3.0: > > bilbo ~ # eselect wxwidgets list > Available wxWidgets profiles: > [1] gtk3-unicode-3.2-gtk3 * > > Should all the other ebuilds in the tree inheriting wxwidgets be updated > similarly? (i.e., call setup-wxwidgets not from pkg_prepare but from > src_configure). There are maaaany of them. I am especially interested about > sci-mathematics/wxmaxima which I maintain. It is currently written in the > more standard way: > > WX_GTK_VER="3.2-gtk3" > inherit wxwidgets > DEPEND="x11-libs/wxGTK:${WX_GTK_VER}[X]" > pkg_prepare() { > setup-wxwidgets > } > > Can somebody who has both 3.0-gtk3 and 3.2-gtk3 installed and 3.0-gtk3 > eselected check if wxmaxima emerges successfully? (I haven't got such bug > reports about it, and on my system, with 3.2-gtk3, it, of course, emerges > fine.) wxmaxima compiled successfully without modification. # eselect wxwidgets list Available wxWidgets profiles: [1] gtk3-unicode-3.0-gtk3 * [2] gtk3-unicode-3.2-gtk3
Typo, instead of pkg_prepare() there should be src_prepare() :) Consider my previous message to be erroneous :) --- crwx-ng-0.3.1-r1.ebuild 2024-02-14 19:10:49.000000000 +0400 +++ crwx-ng-0.3.1-r2.ebuild 2024-06-20 13:45:05.221127611 +0400 @@ -20,6 +20,7 @@ RDEPEND="${CDEPEND} virtual/ttf-fonts" -pkg_prepare() { +src_prepare() { setup-wxwidgets + cmake_src_prepare } It works this way. What is better to use src_prepare() or src_configure() I don’t know, maybe it can be done as in most cases?
wxwidgets@gentoo.org, could you please answer a few questions? 1. From which phase function should setup-wxwidgets be called? The current statistics of the packages in the tree is: src_configure 66 src_prepare 16 pkg_setup 6 pkg_prepare 1 Does this mean that one of these groups is right, and the other 3 ones are wrong and should be fixed? 2. Suppose a user has 2 slots installed, 3.0-gtk3 and 3.2-gtk3. [S]he can eselect one of them. The slot used during emerging a package should depend only on WX_GTK_VER in the ebuild, and must not depend on which slot is currently eselected. Does wxwidgets.eclass guarantee this? 3. Where should x11-libs/wxGTK:${WX_GTK_VER}[something] appear - in what subset of DEPEND, BDEPEND, RDEPEND?
