Hi Alan,
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, June 27, 2017 1:06 AM
> To: Arjen Markus; PLplot development list; Phil Rosenberg; Pedro Vicente
> Subject: RE: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2
>
> 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.
Well, not entirely - see below.
>
> 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)'
>
...
>
> 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!
>
Last night I installed the 32-bits version of MinGW-w64/SYS2 and that built
wxWidgets without any trouble. So the reports about "64 bits MinGW" being at
fault are not entirely incorrect.
The trouble came from a different source: the haru library needed for the PDF
device. This turns out to be built using the "stdcall" convention (one of the
reasons I greatly prefer to work with 64 bits on Windows!) and thus I got error
messages like the ones below:
[ 19%] Linking C shared module ../dll/pdf.dll
cd /D/plplot-svn/build-mingw-alt/drivers && /D/mingw32/mingw32/bin/cmake.exe -E
remove -f CMakeFiles/pdf.dir/objects.a
cd /D/plplot-svn/build-mingw-alt/drivers && /D/mingw32/mingw32/bin/ar.exe cr
CMakeFiles/pdf.dir/objects.a "CMakeFiles/pdf.dir/pdf.c.obj"
cd /D/plplot-svn/build-mingw-alt/drivers && /D/mingw32/mingw32/bin/gcc.exe
-shared -o ../dll/pdf.dll -Wl,--major-image-version,0,--minor-image-version,0
-Wl,--whole-archive CMakeFiles/pdf.dir/objects.a -Wl,--no-whole-archive
../dll/libplplot.dll.a /D/mingw32/mingw32/lib/libhpdf.dll.a
/D/mingw32/mingw32/lib/libshp.dll.a /D/mingw32/mingw32/lib/libfreetype.dll.a
../dll/libcsirocsa.dll.a ../dll/libcsironn.dll.a
/D/mingw32/mingw32/lib/libqhull.dll.a ../dll/libqsastime.dll.a -lkernel32
-luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32
-ladvapi32
CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x293): undefined
reference to `_imp__HPDF_New'
CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x2d1): undefined
reference to `_imp__HPDF_SetCompressionMode'
CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x423): undefined
reference to `_imp__HPDF_AddPage'
CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x45a): undefined
reference to `_imp__HPDF_Page_SetSize'
CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x47e): undefined
reference to `_imp__HPDF_Page_SetSize'
CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x48e): undefined
reference to `_imp__HPDF_Page_GetWidth'
As I know the origin of these errors, it might be easy (or not) to fix this.
> 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!
>
Yes, I will have a look at the MSVC variant and leave this issue to you. Not
sure how much time I can spend though, we'll see.
Regards,
Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
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
