CYGWIN: cannot build anymore because (Issue #23674)
Carlo Bramini
Description
I cloned the repo, for testing issue #23673 on the latest source available at the time of writing.
Unfortunately, the process hangs almost at the beginning with this error:
$ ninja
[1/695] Building CXX object libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/fdiodispatcher.cpp.o
FAILED: libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/fdiodispatcher.cpp.o
/usr/bin/c++.exe -DWXBUILDING -DWXDLLNAME=wx_baseu-3.3 -DWXMAKINGDLL_BASE -DWX_PRECOMP -D_FILE_OFFSET_BITS=64 -D__WXGTK3__ -D__WXGTK__ -DwxUSE_BASE=1 -DwxUSE_GUI=0 -Dwxbase_EXPORTS -I/usr/include/libsecret-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/wx/lib/wx/include/gtk3-unicode-3.3 -I/wxWidgets/include -g -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual -pthread -std=gnu++11 -Winvalid-pch -include /wx/libs/base/CMakeFiles/wxbase.dir/cmake_pch.hxx -MD -MT libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/fdiodispatcher.cpp.o -MF libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/fdiodispatcher.cpp.o.d -o libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/fdiodispatcher.cpp.o -c /wxWidgets/src/common/fdiodispatcher.cpp
In file included from /wxWidgets/src/common/fdiodispatcher.cpp:28:
/wxWidgets/include/wx/private/selectdispatcher.h:73:5: error: ‘fd_set’ does not name a type
73 | fd_set m_fds[Max];
| ^~~~~~
/wxWidgets/include/wx/private/selectdispatcher.h:104:36: error: ‘fd_set’ does not name a type
104 | void DoProcessFD(int fd, const fd_set& fds, wxFDIOHandler *handler,
| ^~~~~~
ninja: build stopped: subcommand failed.
Support for CYGWIN in the current master has been broken by this commit:
This new definiton of __USE_W32_SOCKETS is checked into sys/select.h and, if it exists, it won't declare anything, causing the above error. When the target platform is CYGWIN, although __USE_W32_SOCKETS allows to do it, in my opinion it would be better to not mix POSIX code with WINSOCK and use pure BSD sockets instead.
Platform and version information
- wxWidgets version git 3bd5063
- wxWidgets port wxGTK
- OS Windows 11
- Compiler CYGWIN + GCC-11.4.0
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Could you please confirm that just reverting 0f2b8a2 fixes the issue? If so, we could just do this because I don't really understand the problem (__USE_W32_SOCKETS is still defined in a header included pretty early, or is too early now?) and would have trouble coming up with a better solution.
FWIW I do agree that Cygwin should use Unix socket code and not Winsock at all, but someone would need to make all the changes to make it happen as I just don't have any motivation for working on Cygwin any more -- while I was a heavy Cygwin user myself for many years, I just don't see any need to use it for building wx when MinGW (cross)compilers seem to be better from all points of view.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Carlo Bramini
I confirm that reverting 0f2b8a2 fixed the issue. However, removing all references to __USE_W32_SOCKETS from both include/wx/defs.h and include/wx/msw/gccpriv.h also worked fine.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Just to be sure: by "work fine" do you mean that it compiled, or did you already check that it actually worked, e.g. the socket unit test passed and/or socket sample worked? Because I'm rather surprised that wxSocket works with both Win32 and Cygwin sockets when it doesn't seem to have any tests for the kind of sockets it uses.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Carlo Bramini
Sorry, when I wrote about "work fine" I was talking about the build process. I also tried to run the test, but I got some errors. This needs some more testing. However, at least I have been able to reach the end with several DLLs and executables.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Thanks, I'll just revert the other commit for now then.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #23674 as completed via 6bd2b6b.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.