I build wxWidgets and/or my application using:
And using MXE to setup/install the cross-compilation environment
../configure --disable-shared --prefix=/opt/mxe/usr/x86_64-w64-mingw32.static --host=x86_64-w64-mingw32.static --build=x86_64-linux --with-gtk=3
make -j16
sudo make install
I don't believe the config.log is relevant, as from the proprocessor defines, there's nothing unintended occurring, but what is intended fails in this (niche) circumstance.
Whenever building wxGTK for Windows, there's a compile error in src/gtk/app.cpp first about wxInitData::Get().argvA not existing (specifically the variable argvA) and (after I changed it to argv before understanding the point of the "A") then an error about conversion about converting from wchar_t to char (specifically pointers, but that's besides the point).
At which point I looked into it a bit more and realized that argvA is supposed to be a char** representation of argv, where argv is normally a (as far as I can tell, as least for this build) a wchar_t**. However, specifically when building for Windows, there's a preprocessor if in wxInitData that removes argvA, and I assume another one whereever the implementation details are of filling argvA.
This causes issues as the gtk init requires a char** representation of argv. As a quick workaround just to build my application, I've done the following in app.cpp:
#if defined(__WXGTK4__) init_result = gtk_init_check() != 0; #else #if defined(__WINDOWS__) auto ORIG_argc_{argc_}; auto argvA = new char*[ORIG_argc_]; for (auto i{0}; i < ORIG_argc_; i++) { auto len{wcslen(argv_[i])}; argvA[i] = new char[len + 1]; argvA[i][len] = '\0'; wcstombs(argvA[i], argv_[i], len); } #else // !defined(__WINDOWS__) auto argvA = wxInitData::Get().argvA; #endif // defined(__WINDOWS__) int argcGTK = argc_; init_result = gtk_init_check( &argcGTK, &argvA ) != 0; if ( argcGTK != argc_ ) { // we have to drop the parameters which were consumed by GTK+ for ( int i = 0; i < argcGTK; i++ ) { while ( strcmp(wxConvUTF8.cWX2MB(argv_[i]), argvA[i]) != 0 ) { free(argv_[i]); memmove(argv_ + i, argv_ + i + 1, (argc_ - i)*sizeof(*argv_)); } } argc_ = argcGTK; argv_[argc_] = nullptr; this->argc = argc_; this->argv.Init(argc_, argv_); } //else: gtk_init() didn't modify our parameters #if defined(__WINDOWS__) for (auto i{0}; i < ORIG_argc_; i++) { delete[] argvA[i]; } delete[] argvA; #endif // defined(__WINDOWS__) #endif // defined(__WXGTK4__)
However I assume that updating the logic in wxInitData to fill argvA should wxWidgets be building for GTK on Windows would do the same (or better), but I've not looked into it that far.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Thanks, there is indeed a problem here, we must change the conditional compilation directives in include/wx/private/init.h
to define argvA
even under Windows if non-wxMSW port is used.
Any PRs doing it would be welcome and it would be really nice to have a CI build testing wxGTK/Windows build if people are really interested in using it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I'm undoubtedly a novice, so setting up testing is beyond me, but I can take a look at updating the directives.
For the moment, I also wanted to add to this (since it's relevant to wxGTK/Windows builds):
It seems that for wxGTK builds on Windows, msw/init.h
is not installed, however app.h
has a directive checking __WINDOWS__
to include msw/init.h
. Previously I hadn't encountered this issue because I had built the wxMSW port, and then installed wxGTK on top of that, so the old files were still there to fill in the gaps.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I think the linked commit should fix the latter problem, please let me know if it doesn't.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Great! I’m out of town (and away from a computer) for the next couple of weeks. I will test it when I get back. :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I think the linked commit should fix the latter problem, please let me know if it doesn't.
I've verified that the msw/init.h is now correctly installed when building wxGTK for Windows, and have submitted a PR to fix the initialization of argvA
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Closed #24611 as completed via b808f4d.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.