Quantcast

compiling on 32-bit mingw

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

compiling on 32-bit mingw

Allin Cottrell
I just tried (cross-)compiling current CVS gnuplot using 32-bit
mingw (something that has worked fine for me in the past), and I see
that recent changes under src/win have made this problematic:

- building wgraph.o fails for lack of the symbols PBS_MARQUEE and
PBM_SETMARQUEE

- building wprinter.o fails for lack of IPrintDialogCallback and
associated stuff

The first of these issues -- as I found by googling -- is fairly
easily solved. It suffices to insert

#ifndef PBS_MARQUEE
# define PBS_MARQUEE 0x08
# define PBM_SETMARQUEE (WM_USER+10)
#endif

before the function CopyPrint() in wgraph.c. But I haven't yet found
a comparable workaround for IPrintDialogCallback and friends.

Allin Cottrell




--
Allin Cottrell
Department of Economics
Wake Forest University

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: compiling on 32-bit mingw

Bastian Märkisch
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.

   Bastian


Am 02.10.2016 um 22:00 schrieb Allin Cottrell:

> I just tried (cross-)compiling current CVS gnuplot using 32-bit
> mingw (something that has worked fine for me in the past), and I see
> that recent changes under src/win have made this problematic:
>
> - building wgraph.o fails for lack of the symbols PBS_MARQUEE and
> PBM_SETMARQUEE
>
> - building wprinter.o fails for lack of IPrintDialogCallback and
> associated stuff
>
> The first of these issues -- as I found by googling -- is fairly
> easily solved. It suffices to insert
>
> #ifndef PBS_MARQUEE
> # define PBS_MARQUEE 0x08
> # define PBM_SETMARQUEE (WM_USER+10)
> #endif
>
> before the function CopyPrint() in wgraph.c. But I haven't yet found
> a comparable workaround for IPrintDialogCallback and friends.
>
> Allin Cottrell
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: compiling on 32-bit mingw

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: compiling on 32-bit mingw

Bastian Märkisch

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: compiling on 32-bit mingw

Allin Cottrell
On Mon, 3 Oct 2016, Bastian Märkisch wrote:

> 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?
Yes, I am. And I could build a 32-bit toolchain under Mingw64. My
observation was not really intended as a complaint, rather a query
as to whether mingw32 is still considered a supported build target.

One other related observation: src/win/wprinter.c has

#include <OCIdl.h>

This header will not be found on mingw, but it is found OK if named
as ocidl.h.

Allin Cottrell
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: compiling on 32-bit mingw

Hans-Bernhard Bröker-2
In reply to this post by Bastian Märkisch
Am 03.10.2016 um 10:37 schrieb Bastian Märkisch:
> 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.

I think you're misinterpreting the symptoms there.  I don't have MinGW32
installed anymore, but at least OpenWatcom has no actual problem with
current gnuplot sources.

The only stumbling stone has been that the definition of WINVER in our
source trees has been broken: it's not seen where it's needed.  The
definition in "syscfg.h" doesn't do us any good for sources that don't
include syscfg.h.

> Btw. Mingw64 and MSVC2015 compile gnuplot just fine

As does OW as of right now.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Loading...