Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Alan W. I. <ir...@be...>]

To Arjen, Phil, and Pedro:


@Phil and Pedro: what set of wxwidgets libraries do you use to test
PLplot wxwidgets components on the MSVC platform?  That information
would be useful to Arjen (see the last part of the rest of this
post).

@Arjen: the rest of this is largely for you.

It turns out I can now finally replicate
the wxwidgets build bug you discovered! I got this result on my
Windows platform consisting of Wine staging 2.10 + an ancient (but
thankfully still working) snapshot of MinGW/MSYS (4.7.2) + epa_build
(on Wine-stagine/MinGW/MSYS) of wxwidgets-3.0.2.  Note that this is a
32-bit platform because the wine command (as opposed to the wine64
command) implements 32-bit Windows, and, in any case, MinGW/MSYS was
always 32-bit as well (unlike MinGW-w64/MSYS2 which implements both
32-bit and 64-bit versions).  So all the web reports saying this issue
was limited to 64-bit platforms is obviously incorrect.

For some reason, the wxwidgets find on this platform plus some of our
further logic in cmake/modules/wxwidgets.cmake to test the wxwidgets
version failed because wxWidgets_INCLUDE_DIRS was in /<drive letter>/
form.  To get around that limitation I have locally implemented some
logic to append a variant of wxWidgets_INCLUDE_DIRS to
wxWidgets_INCLUDE_DIRS that has been converted from that form to the
corresponding <drive letter>:/ form.  I have no idea why this change
is necessary but it does work, and I don't think it will interfere
with anything else so I plan to finalize and commit this change (even
though you don't seem to have encountered this issue on
MinGW-w64/MSYS2).

The initial error message (similar to what you reported) is

z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/include/wx-3.0/wx/msw/winundef.h:38:20:
error: cannot convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}' for argument '2' to 'HWND__*
CreateDialogParamW(HINSTANCE, LPCWSTR, HWND, DLGPROC, LPARAM)'

My test that generated that error was the following command (on one
line rather than e-mail wrapped as here)

${EPA_BUILD_SOURCE_PATH}/../../scripts/comprehensive_test.sh --prefix
comprehensive_test_disposable --generator_string "MSYS Makefiles"
--cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON
-DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON
-DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON" --build_command make
--ctest_command ctest --do_nondynamic no --do_static no
--do_test_noninteractive no --do_ctest no --do_test_install_tree no
--do_test_traditional_install_tree no

Those options mean the results are limited to the wxwidgets components
of PLplot, and to speed the test (for now) just interactive testing is
done for just the shared libraries case and just the build tree.  So
this is roughly equivalent to some hand-tests you have been making
with the advantage of a generated tarball report (attached) that
includes essentially all details in standard form to help debug this
issue further.

Since I can now replicate the issue you found, and I still view this
issue as release critical I intend to work on it until I solve it. 
Of course, you are welcome to continue to work on this issue (e.g., by
trying a 32-bit MinGW-w64/MSYS2 build [which from the above 32-bit
evidence will probably generate the equivalent build error, but you
never know], beating me to a solution, or adding some essential
insight that helps me find a solution). However, it would likely be
more efficient (in terms of reaching the goal of getting the next
release out in a timely manner) if you switched to testing wxwidgets
for the MSVC case. According to Phil's tests, wxwidgets did work fine
for the MSVC platform just before we released PLplot-5.12.0 so it is
definitely release critical if it turns out wxwidgets no longer works
on that platform!

If you are willing to move to testing our wxwidgets components for
MSVC, then one issue is how do you gain access to the wxwidgets
libraries for the MSVC platform? The web advice concerning that issue
seems to be pretty uniform which (presumably because of ABI
consistency issues) is to build your own wxwidgets libraries using the
identical compiler that you use to build your wxwidgets application
(or wxwidgets-related PLplot applications and libraries in our case).
My initial google search found
<https://stackoverflow.com/questions/37995066/how-to-set-up-wxwidgets-3-1-0-with-visual-studio-2015>
which contains a summary of what is needed in the MSVC case, but your
own google searches may find a better reference.  And if either or
both Phil or Pedro respond to the question above, that should help as
well!

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________