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

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> 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.