DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 5A7ICdql3729893
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2CAC93858D1E
Message-ID: <b33de20f-5753-487a-8bdc-1180e5fcea67@hamishmb.com>
Date: Fri, 7 Nov 2025 18:11:13 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Help wanted with compile error with wxWidgets3.1
To: cygwin AT cygwin DOT com
References: <76f19efc-f06d-4bb2-ac32-edc846394cc3 AT hamishmb DOT com>
 <7b8f2904-26a2-44b6-b97d-fbc7c8f4df2c AT SystematicSW DOT ab DOT ca>
Content-Language: en-US
In-Reply-To: <7b8f2904-26a2-44b6-b97d-fbc7c8f4df2c@SystematicSW.ab.ca>
Precedence: list
From: Hamish McIntyre-Bhatty via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Hamish McIntyre-Bhatty <cygwin AT hamishmb DOT com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

On 04/10/2025 21:40, Brian Inglis via Cygwin wrote:
> On 2025-10-03 05:58, Hamish McIntyre-Bhatty via Cygwin wrote:
>> I'm trying once again to get newer versions of wxWidgets and wxPython 
>> to work under Cygwin, but I've noticed I'm running into a new problem 
>> when simply rebuilding wxWidgets 3.1.5 that I last built around the 
>> end of March (the prefix option to configure needed to be set), and I 
>> don't understand how it ever compiled with the error I'm getting.
> 
> 
> BUILD_REQUIRES="..."
> 
> can be split into lines within the string
> 
> BUILD_REQUIRES="...
> ..."
> 
> for easier readability, and, given cygport runs under bash, the second 
> instance for checking can drop $BUILD_REQUIRES and use:
> 
> BUILD_REQUIRES+=" ...
> ..."
> 
> you can also normally drop libPKG# if you specify libPKG-devel because 
> devel packages always require their latest library package; for example:
> 
> BUILD_REQUIRES="gettext-devel libcogl-devel libEGL-devel libexpat-devel
> libGL-devel libGLU-devel libgstreamer1.0-devel libgstinterfaces1.0-devel
> libgtk2.0-devel libgtk3-devel libiconv-devel libjpeg-devel libmspack-devel
> libnotify-devel libpng-devel libSDL2-devel libSDL2_image-devel
> libSDL2_mixer-devel libSDL2_net-devel libSDL2_ttf-devel
> libsecret1-devel libSM-devel libtiff-devel
> libwebkitgtk1.0-devel libwebkitgtk3.0-devel
> libX11-devel libXpm-devel libXtst-devel liblzma-devel zlib-devel
> autoconf cppunit doxygen gcc-core gcc-g++ make pkg-config"
> # gettext libsecret1_0
> 
> For remote patches, I define the patch source URI prefix like:
> 
> FEDORA=https://src.fedoraproject.org/rpms/wxGTK3/raw/f38/f
> 
> as it is more readable, reproducible, and consistently runnable, if I 
> specify the latest Fedora release *in the current repo*, rather than 
> main, master, or rawhide, which may change any time and drop or update 
> patches which no longer apply; for example:
> 
> FEDORA=https://src.fedoraproject.org/rpms/wxGTK3/raw/f38/f
> 
> PATCH_URI="
>      $FEDORA/wxGTK3-3.0.3-abicheck.patch
>      fix-filename-test-wx31.patch
>      $FEDORA/force-x11-for-wxgl.patch
> ...
> "
> 

Thanks for all that, I've taken it onboard and it does make the cygport 
file much cleaner.

> Under src_compile, rather than running configure directly, you could 
> define CYGCONF_ARGS with the common options before the function, and 
> invoke cygconf with specific options, and that will also provide any 
> other definitions required for, and perform commands with expected 
> options to make Cygwin builds; for example:
> 
> CYGCONF_ARGS="
>       --enable-mediactrl
>       --enable-optimise
>      --disable-rpath
>       --enable-unicode
>         --with-expat
>         --with-libpng
>         --with-libjpeg
>         --with-libiconv
>         --with-libmspack
>         --with-libnotify
>         --with-libtiff
>         --with-libxpm
>         --with-opengl
>         --with-regex=sys
>         --with-sdl
>         --with-zlib
> "
> #     --prefix=/usr
> #     --enable-shared
> 
> src_compile() {
>      local myconf
> 
>      pushd ${S}
> 
>      pushd ${S}/locale
>      rm -f *.mo
>      cygmake allmo -j1
>      popd
> 
>      mkdir -p ${B}/gtk2
>      pushd ${B}/gtk2
> 
>      cygconf --with-gtk=2
>      cygmake
> 
>          popd
> 
>      mkdir -p ${B}/gtk3
>      pushd ${B}/gtk3
> 
>      cygconf --with-gtk=3
>      cygmake
> 
>      popd
> ...
> }
> 

This seems like a good idea, but I get the following error from the 
configure script when I do it that way:

"
configure: error:
     CATCH (C++ Automated Test Cases in Headers) is required, the 
required file
     /3rdparty/catch/include/catch.hpp couldn't be found.

     You might need to run

         git submodule update --init 3rdparty/catch

     to fix this.
"

I have confirmed that the file is indeed there, and that when I run the 
configure script directly it works just fine. Any ideas why that might be?

> Sometimes it is better to allow packages which can, detect whether and 
> which options are required in your environment, and for you to check 
> whether options are appropriately detected and enabled or disabled, or 
> added to your list.
>> In amongst other errors, I get "error: wxSoundPLaybackStatus does not 
>> name a type" and various similar errors. You can get the repo with the 
>> full cygport setup here: https://gitlab.com/hamishmb/cygwin- 
>> wxwidgets3.1/-/tree/3.1.5? ref_type=heads
> Sure that capitalization is correct: wxSoundP'L'aybackStatus?
> Check the library docs, online docs, dev sites, and online repos.
> 

That capitalisation was a typo from me when writing the email, my 
apologies for that. I'll get to these issues once I can sort the new 
configure script problem, same goes for your suggestions, ASSI.

> It appears that wxSoundPLaybackStatus could be either a typo for, or 
> intended as a variable with, type wxSoundPlaybackStatus, maybe in wx/ 
> sound.h?
> 
>> Can anyone give me any hints? I first tried building wxWidgets 3.1.7 
>> but that failed with a different error that I also don't know how to 
>> solve. I'm not sure how I'm meant to know which header file things are 
>> meant to be in when I get "was not declared in this scope" errors - 
>> any hints with those or do I just need to be intimately familiar with 
>> GNU source code for that?
> 
> To find headers with symbols, start with:
> 
> $ grep -R symbol /usr/include/
> $ cygcheck -f /usr/include/**/header.h
> 
> or if not installed (remember - egrep patterns - may need ''s; no 
> absolute paths - all relative to install root):
> 
> $ cygcheck -p usr/include/.*header.h
> $ cygcheck -p usr/lib/gcc/x86_64-pc-cygwin/.*/include/.*header.h
> $ cygcheck -p usr/lib/gcc/x86_64-pc-cygwin/.*/include/c++/.*header.h
> $ cygcheck -p header.h
> 
> for example:
> 
> $ grep -R wxSoundPlaybackStatus /usr/include/
> $ cygcheck -f /usr/include/**/wx/sound.h
> $ cygcheck -p wxSoundPlaybackStatus
> Found 0 matches for wxSoundPlaybackStatus
> $ cygcheck -p usr/include/.*wx/sound.h
> Found 7 matches for usr/include/.*wx/sound.h
> libwx_baseu3.0-devel-3.0.4-1 - libwx_baseu3.0-devel: wxWidgets C++ 
> application framework
> libwx_baseu3.0-devel-3.0.5.1-1 - libwx_baseu3.0-devel: wxWidgets C++ 
> application framework
> libwx_baseu3.0-devel-3.0.5.1-2 - libwx_baseu3.0-devel: wxWidgets C++ 
> application framework
> libwx_baseu3.1-devel-3.1.5-1 - libwx_baseu3.1-devel: wxWidgets C++ 
> application framework
> libwx_baseu3.1-devel-3.1.5-2 - libwx_baseu3.1-devel: wxWidgets C++ 
> application framework
> libwx_gtk2u2.8-devel-2.8.12.1-6 - libwx_gtk2u2.8-devel: wxWidgets C++ 
> application framework (development)
> libwx_gtk2u2.8-devel-2.8.12.1-7 - libwx_gtk2u2.8-devel: wxWidgets C++ 
> application framework (development)

Thanks for all that, that should prove invaluable I think.

> 
> 
>> Please note I'll be on holiday soon so I may not reply quickly.
> 


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple