Re: compiling on 32-bit mingw

[Bastian M. <bma...@we...>]

Am 03.10.2016 um 10:53 schrieb Mojca Miklavec:
> On 3 October 2016 at 10:37, Bastian Märkisch wrote:
>> Sigh. MinGW32 is falling behind rather seriously. IPrintDialogCallback
>> and friends have been part of the API since Windows 2000 Pro according
>> to MSDN. Mingw32 is currently also lacking support for several other
>> "modern" APIs like Direct2D, DirectWrite and touch, which gnuplot might
>> use in the near future. This is also not the only development
>> environment with that problem: OpenWatcom's library is seriously out of
>> date, too.
>>
>> To fix compilation with MinGW32 for now, we could add the old code back
>> along with a number of #ifdef's, or extract the missing definitions from
>> MSDN and add them to the our code (easily around 100 lines), or #ifdef
>> out the affected code and functionality.
>>
>> Btw. Mingw64 and MSVC2015 compile gnuplot just fine.
>
> This is not my area of expertise, but isn't MinGW-w64 a suitable
> replacement for MinGW32?
>
> I kind-of gave up on the original MinGW32, in particular in the area
> of cross-compiling. MinGW-w64 seems much better supported and more
> up-to-date (not to even mention the ability to create 64-bit
> binaries).
>
> It would be one thing to exclude everyone without MSVC. That would be
> a bit sad. But I don't find it problematic to ask *developers* (the
> few people who actually know how to compile under Windows and how to
> get all the dependencies working) to switch to a different OpenSource
> toolchain, in particular if supporting the "old" toolchain causes
> additional headaches and more ugly code.
>
> If gnuplot compiles fine under MinGW-w64, I don't see any reason to
> use ugly workarounds in the code just for the sake of supporting an
> alternative tool that lags behind.
>
> Mojca
>

Agreed. Except that MinGW32 was the recommended toolchain until 
recently. So we shouldn't give up too quickly.
Allin, aren't you using Mingw64 for 64bit builds already?

   Bastian