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
