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 __________________________
mingw_msys_comprehensive_test.tar.gz
Description: comprehensive test report for wxwidgets components on Wine/MinGW/MSYS
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
