Re: Test: wxWidgets3.1 3.1.5-2

On 07/02/2026 16:58, Jon Turney wrote:
> On 04/02/2026 15:23, Hamish McIntyre-Bhatty via Cygwin wrote:
>> On 03/02/2026 19:24, Jon Turney wrote:
>>> On 25/03/2025 16:46, Hamish McIntyre-Bhatty via Cygwin-announce wrote:
>>>> Version 3.1.5-2 of "wxWidgets3.1" has been uploaded as a test package.
>>>>
> [...]
>>>
>>> First off, configure fails.  This seems to be due to:
>>>
>>>> $ wx-config-3.1 --cflags
>>>> -I/usr/local/lib/wx/include/gtk3-unicode-3.1 -I/usr/local/include/ 
>>>> wx-3.1 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__
>>>
>>> I'm not sure how 'local' got in there, but I don't think that's right!
>> No, I wasn't sure either, hence I never promoted this to stable. I've 
>> since realised I need extra configure options, but it doesn't build 
>> any more, sadly. See my "help wanted" messages to the list for more 
>> details if you like. I'll give it another go at some point. 
>> Unfortunately I don't think I really have the time or skill to sort 
>> out the compilation issues.
>
> Hmmm... it's disappointing but sadly expected that no one took the 
> time to reproduce your build and investigate the problem.
>
>
> Anyhow:
>
> 'local' is appearing, because you're calling ./configure directly 
> rather than via cygconf (which sets --prefix=/usr and other useful 
> stuff).
>
> I see that you're using cygconf because otherwise configure fails 
> looking for catch.hpp.
>
>> configure: error:
>>     CATCH (C++ Automated Test Cases in Headers) is required, the 
>> required file
>>     /3rdparty/catch/include/catch.hpp couldn't be found.
> The clue here is the path it's looking for starting in the root 
> directory, which can't possibly be right.
>
> Peering at the configure script, it's looking for this file relative 
> to $ac_confdir, but that variable isn't set if the --srcdir option is 
> supplied (which cygconf does).
>
> (This seems like an upstream bug as it could be using $srcdir instead?)
>
> This could be patched around, but it's just as easy to define 
> ac_confdir as it's expecting.
>
>
>
> Then there's the problem with "error: wxSoundPLaybackStatus does not 
> name a type":
>
> In fact there's a lot of errors here, but they're all coming from 
> trying to compile one source file: src/unix/sound_sdl.cpp.
>
> This is a case where it's useful to look at the first error: 
> "‘WXHINSTANCE’ has not been declared".
>
> This is a big red flag because a Win32 API type like HINSTANCE 
> probably shouldn't be being used in a Cygwin build. And looking at the 
> code where this appears in wx/utils.h, it's guarded by __WINDOWS__ 
> with a comment saying "Windows only".
>
> Rooting around a bit, __WINDOWS__ is defined inside wxWindows when 
> building for the Win32 API. But that's not being turned on! So where 
> can it be coming from?
>
> Looking further (by adding a '#define __WINDOWS__ foo' to the source 
> file, which gets us a warning showing where the location of the 
> previous definition with a different value is), it's coming from the 
> SDL.h header included by it.
>
> I guess that's new with an updated version of SDL since the last time 
> you built this. But it's fairly easy to workaround by undefining it 
> there.
>
> (This is why you namespace symbols in public include files, kids! And 
> actually this is doubly terrible, because the __ namespace is already 
> reserved for the language implementation; §7.1.3 of C99 etc.)
>
>
> I pushed a few patches to:
>
> https://cygwin.com/cgit/cygwin-packages/wxWidgets3.1/log/?h=playground
>
> ... maybe those can help you get unstuck.
>
>>> Secondly, wxUSE_FSWATCHER doesn't seem to get defined.
>>>
>>> Not sure if that's expected? Using the windows backend for 
>>> filewatching probably requires some extra work with file conversions, 
>
> I meant 'pathname conversions' here, of course.
>
>>> but the generic polling backend should be usable?
>> I think this might have something to do with sys/epoll.h being 
>> missing, if memory serves. I think that might simply be something 
>> that's not available on Cygwin, I'm not sure.
>
> Not sure.  I took a poke at this as code for something called the 
> "generic polling filewatcher", but it doesn't actually seem to be 
> possible to configure wxWidgets to use it?
>
>>> Then I run into some wchar_t/wxstring conversion issues which I'm 
>>> not sure should be happening in a unicode build, but seem fixable...
>>>
>>> (You can see where I got to at https://cygwin.com/cgit/cygwin- 
>>> packages/poedit/tree/?h=playground, if you're interested)
>>>
>> I wonder if a build of wxWIdgets 3.2 might fix the problem. I shall 
>> give that a go. Unfortunately due to the stack watcher being 
>> unsupported on Cygwin (IIRC), newer versions of wxPython may be a no-go.
> This is because of a dependency on libbacktrace, which we don't 
> currently have, right?
>
> Someone ought to look into that. :) 

Well, it compiles now, so thanks for all your help :)

Now I just need to test it. I'll probably do that by compiling wxPython 
(assuming that works) and running all aspects of the demo.

I did try 3.1.7 but due to a locale issue that looks like a coding error 
it doesn't work. I'll try 3.1.6 and see if that's a happy medium, or if 
there are gentoo patches or similar for 3.1.7.

Best,

Hamish


-- 
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