gnuplot-beta

Re: 5.2 rc2 tarball now available

[Daniel J S. <dan...@ie...>]

On 07/05/2017 05:08 PM, Petr Mikulik wrote:
>>>>>> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some
>>>>>> Ubuntu) linking fails.
>>>>>>
>>>>>> It is this problem:
>>>>>>      https://sourceforge.net/p/gnuplot/support-requests/196/
>>>>>>
>>>>>> The workaround
>>>>>>      configure --with-X11
>>>>>> described above does not help, while
>>>>>>      TERMLIBS="-lX11" ./configure
>>>>>> let me gnuplot compile.
>>>>>>
>>>>>> Can this be fixed?
>>>>>
>>>>>   No.  It is a bug in the configuration files distributed for
>>>>> libwxgtk.
>>>>
>>>> Unfortunately it seems to be a wide-spread bug. It is quite
>>>> embarassing that a
>>>> compile needs googling to fix it locally.
>>>>
>>>> Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
>>>> "something"?
>>>
>>> That "something" is exactly the problem.   Only some versions of
>>> wxWidgets need this, and only for some configurations.   The
>>> wx-config tool is supposed to tell us what libraries are needed so
>>> we can link them.  But it doesn't mention X11.    So how are we to know?
>>
>> Actually, I think this is gnuplot's responsibility.  If I do
>
>> Anyway, I think gnuplot configure is obligated to add -lX11, given the
>> situation.
>
> I think that ./configure is the place for tests of compile conditions.
> There can be some simple case testing whether "-lX11" is needed or not.
> Is such a workaround possible?

The necessary tests are already present.  The hunks of code that matter 
have pre-processor conditionals:

#if defined(WX_NEEDS_XINITTHREADS) && defined(X11)
#include <X11/Xlib.h>	/* Magic fix for linking against wxgtk3.0 */
#endif

and WX_NEEDS_XINITTHREADS and X11 are defined from tests within the 
configure process.

We only want to include library -lX11 for the building of wx_gui.cpp, 
and there is a convenient definition for that:

Makefile:LIBRARIES_FOR_X =  -lX11

The included libraries for wx_gui.cpp are gotten from the wx-config 
command as discussed earlier, and it shows up as

Makefile:WX_LIBS = -L/usr/lib/x86_64-linux-gnu -pthread 
-lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 
-lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 
-lwx_baseu_net-3.0 -lwx_baseu-3.0  -lpangocairo-1.0 -lpango-1.0 -lcairo 
-lgobject-2.0 -lglib-2.0

So, all we really need do is append LIBRARIES_FOR_X to WX_LIBS if 
XInitThreads() is used in the wx_gui code.  If X11 is not present, 
LIBRARIES_FOR_X should be empty.

I've attached a six-line patch to the original bug report associated 
with the inclusion of XInitThreads() here:

https://sourceforge.net/p/gnuplot/bugs/_discuss/thread/94192961/d1c5/attachment/gnuplot-wxlibs_xinitthreads_configure-djs2017jul06.patch

Dan

Re: 5.2 rc2 tarball now available

[sfeam <sf...@us...>]

On Thursday, 06 July 2017 12:38:13 Daniel J Sebald wrote:
> On 07/05/2017 05:08 PM, Petr Mikulik wrote:
> >>>>>> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some
> >>>>>> Ubuntu) linking fails.
> >>>>>>
> >>>>>> It is this problem:
> >>>>>>      https://sourceforge.net/p/gnuplot/support-requests/196/
> >>>>>>
> >>>>>> The workaround
> >>>>>>      configure --with-X11
> >>>>>> described above does not help, while
> >>>>>>      TERMLIBS="-lX11" ./configure
> >>>>>> let me gnuplot compile.
> >>>>>>
> >>>>>> Can this be fixed?
> >>>>>
> >>>>>   No.  It is a bug in the configuration files distributed for
> >>>>> libwxgtk.
> >>>>
> >>>> Unfortunately it seems to be a wide-spread bug. It is quite
> >>>> embarassing that a
> >>>> compile needs googling to fix it locally.
> >>>>
> >>>> Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
> >>>> "something"?
> >>>
> >>> That "something" is exactly the problem.   Only some versions of
> >>> wxWidgets need this, and only for some configurations.   The
> >>> wx-config tool is supposed to tell us what libraries are needed so
> >>> we can link them.  But it doesn't mention X11.    So how are we to know?
> >>
> >> Actually, I think this is gnuplot's responsibility.  If I do
> >
> >> Anyway, I think gnuplot configure is obligated to add -lX11, given the
> >> situation.
> >
> > I think that ./configure is the place for tests of compile conditions.
> > There can be some simple case testing whether "-lX11" is needed or not.
> > Is such a workaround possible?
> 
> The necessary tests are already present.  The hunks of code that matter 
> have pre-processor conditionals:
> 
> #if defined(WX_NEEDS_XINITTHREADS) && defined(X11)
> #include <X11/Xlib.h>	/* Magic fix for linking against wxgtk3.0 */
> #endif
> 
> and WX_NEEDS_XINITTHREADS and X11 are defined from tests within the 
> configure process.
> 
> We only want to include library -lX11 for the building of wx_gui.cpp, 
> and there is a convenient definition for that:
> 
> Makefile:LIBRARIES_FOR_X =  -lX11
> 
> The included libraries for wx_gui.cpp are gotten from the wx-config 
> command as discussed earlier, and it shows up as
> 
> Makefile:WX_LIBS = -L/usr/lib/x86_64-linux-gnu -pthread 
> -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 
> -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 
> -lwx_baseu_net-3.0 -lwx_baseu-3.0  -lpangocairo-1.0 -lpango-1.0 -lcairo 
> -lgobject-2.0 -lglib-2.0
> 
> So, all we really need do is append LIBRARIES_FOR_X to WX_LIBS if 
> XInitThreads() is used in the wx_gui code.  If X11 is not present, 
> LIBRARIES_FOR_X should be empty.
> 
> I've attached a six-line patch to the original bug report associated 
> with the inclusion of XInitThreads() here:
> 
> https://sourceforge.net/p/gnuplot/bugs/_discuss/thread/94192961/d1c5/attachment/gnuplot-wxlibs_xinitthreads_configure-djs2017jul06.patch

Unfortunately that doesn't work.

As it shows in the original bug report, wxgtk stupidly insists on the 
XInitThreads business  *even if the program doesn't use X11*. 

So making gnuplot's configuration rely on LIBRARIES_FOR_X doesn't
resolve the original problem.  It just moves the failure from compile-time
to run-time.  You can test this by configuring like this:

 ./configure --without-x --without-gd --with-wx

Your patch allows it to compile without complaint, but then you get
a run-time failure instead because wxgtk aborts when it finds that 
XInitThreads was not called.

This is actually worse than the compile-time failure because at that
point it's too late to fix the problem.  
Hence the warning in the Release Notes.

	Ethan


NB: --without-gd is there because the gd configure tool actually gets this right 
and pulls in -lX11 if libgd wants it. If the wxgtk configure tool did the same 
we wouldn't have this problem.
 




> 
> Dan
> 
> ------------------------------------------------------------------------------
> 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
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: 5.2 rc2 tarball now available

[Ethan A M. <sf...@us...>]

On Tuesday, 04 July, 2017 17:26:11 Petr Mikulik wrote:
>  	Hello,
> 
> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some Ubuntu) - 
> linking fails.
> 
> It is this problem:
>      https://sourceforge.net/p/gnuplot/support-requests/196/
> 
> The workaround
>      configure --with-X11
> described above does not help, while
>      TERMLIBS="-lX11" ./configure
> let me gnuplot compile.
> 
> Can this be fixed?
> 
> ***
> 
> Further, I can see that
>  	set term qt; test
> does not pass the test of character width (testing rectangle is too narrow), 
> while x11 and wxt pass well.
> 
> ***
> 
> Those two dummy terminals show 90123456789 instead of 0123...90123...9 in the 
> character width test:
>  	set term dumb; test
>  	set term caca; test
> 
> ***
> 
> Is caca still experimental?
> It's just fun, but it's nice, mouseable and it seems to work, so I propose to 
> have it not experimental.
> 
> ***
> 
> Greetings,
>    Petr

Updates:

1) Auto-detection of a wxt on linux requirement for 
	TERMLIBS="-lX11" ./configure

No solution.  The weak point is the wxgtk3 library.
It has several runtime glitches in addition to this configuration issue.  
I do not expect a fix for 5.2  This is a real problem but I don't see
anything we can do about it other than to recommend against using wxgtk
versions higher than 2.8

2) Qt text boxes

I have modified the "test" command to show both the true bounding box
as used by the current terminal (shaded rectangle) and the generic
estimated bounding box used by the core program to reserve space for
text in a plot layout.  It seems some Qt versions report an inaccurate
bounding box width for some fonts (e.g. Qt 5.6.2 + DejaVu Sans).
Nevertheless the terminal's internal bounding box is always more accurate
than the generic estimated box.

Dan Sebald has pointed out that the Qt terminal and the cairo terminals
differ in whether they increase the lower bound of the bounding box to
allow for font descenders.   This is probably fixable but I consider it a
minor issue.  

3) caca terminal still EXPERIMENTAL?

I have libcaca 0.99 beta18.  The gnuplot caca terminal reports:
set term caca driver list
    x11 gl slang ncurses raw null

For me the x11 and gl options are usable although the x11 font handling
has artifacts.  slang and ncurses spew garbage.  raw and null cause
segfaults.  Most of the time changing a caca option causes gnuplot to exit.
So yes, I think we need to warn that the caca terminal is still EXPERIMENTAL.

4) autoconfigure/compile on SunOS

Minor issues only.  The demo for building and linking plugins does
not autoconfigure correction but can be built manually following instructions
in the plugin demo Makefile.
See also various notes attached to Bug #1821

5) Unwanted inclusion of Type 3 fonts in cairo pdf output

The is Bug #1868.  No fix known.   Not a release-blocker.
It would be great if someone would pursue this with the cairographics
project maintainers.

6) Any other known issues?

	Ethan

Re: 5.2 rc2 tarball now available

[Tatsuro M. <tma...@ya...>]

> 6) Any other known issues?
>
>     Ethan
>
This is not an issue but documentation problem for source distribution.
In source distribution, there is a file named "INSTALL".
It is well written but some parts are obsoleted or inadequate.

e.g.

1. 
Unix, configure
---------------
    
TERMLIBS="-lX11" ./configure
is required for wxwidgets but is not described

2.
MS-Windows
----------

There's no installer for gnuplot, so if you want a desktop link,
program manager group or an association of *.plt or *.gpl files to
wgnuplot, you'll have to do all that yourself.

The gnuplot for windows has installer now.


*********************
There are much points which are not up-to-date.
Is it better open a bug ticket for "INSTALL" being up-to-date?

Tatsuro

Re: 5.2 rc2 tarball now available

[Ethan A M. <sf...@us...>]

On Friday, 14 July, 2017 07:36:26 Tatsuro MATSUOKA wrote:
> > 6) Any other known issues?
> >
> >     Ethan
> >
> This is not an issue but documentation problem for source distribution.
> In source distribution, there is a file named "INSTALL".
> It is well written but some parts are obsoleted or inadequate.
> 
> e.g.
> 
> 1. 
> Unix, configure
> ---------------
>     
> TERMLIBS="-lX11" ./configure
> is required for wxwidgets but is not described
> 
> 2.
> MS-Windows
> ----------
> 
> There's no installer for gnuplot, so if you want a desktop link,
> program manager group or an association of *.plt or *.gpl files to
> wgnuplot, you'll have to do all that yourself.
> 
> The gnuplot for windows has installer now.
> 
> 
> *********************
> There are much points which are not up-to-date.

Good point.
The FAQ, the man page, and the LaTeX tutorial are even more out of date.
Contributions are welcome for all of these.

The same is true for the web site.
The front page is not bad, but the linked pages are getting stale.


> Is it better open a bug ticket for "INSTALL" being up-to-date?

A bug ticket is less useful than a patch containing new text.
Or contribute new text by posting it here on the mailing list.

	Ethan



> Tatsuro

Re: 5.2 rc2: new text for INSTALL

[Jim M. <jm...@ro...>]

INSTALL currently contains

Ubuntu:
         ./configure fails to find lua support because Ubuntu packages it as
         "lua5.1" rather than "lua".  You can fix this by adding a symlink
         prior to running ./configure
             ln -s /usr/lib/pkgconfig/lua5.1.pc /usr/lib/pkgconfig/lua.pc

Installation on linux mint mate 18.2 (based on Ubuntu 16.04) did not 
require this link.

For older 64 bit systems this should be changed to (update "5.1" to 
current version):
ln -s /usr/lib/x86_64-linux-gnu/pkgconfig/lua5.1.pc 
/usr/lib/x86_64-linux-gnu/pkgconfig/lua.pc





On 07/13/2017 04:48 PM, Ethan A Merritt via gnuplot-beta wrote:
> On Friday, 14 July, 2017 07:36:26 Tatsuro MATSUOKA wrote:
>>> 6) Any other known issues?
>>>
>>>      Ethan
>>>
>> This is not an issue but documentation problem for source distribution.
>> In source distribution, there is a file named "INSTALL".
>> It is well written but some parts are obsoleted or inadequate.
>>
>> e.g.
>>
>> 1.
>> Unix, configure
>> ---------------
>>      
>> TERMLIBS="-lX11" ./configure
>> is required for wxwidgets but is not described
>>
>> 2.
>> MS-Windows
>> ----------
>>
>> There's no installer for gnuplot, so if you want a desktop link,
>> program manager group or an association of *.plt or *.gpl files to
>> wgnuplot, you'll have to do all that yourself.
>>
>> The gnuplot for windows has installer now.
>>
>>
>> *********************
>> There are much points which are not up-to-date.
> Good point.
> The FAQ, the man page, and the LaTeX tutorial are even more out of date.
> Contributions are welcome for all of these.
>
> The same is true for the web site.
> The front page is not bad, but the linked pages are getting stale.
>
>
>> Is it better open a bug ticket for "INSTALL" being up-to-date?
> A bug ticket is less useful than a patch containing new text.
> Or contribute new text by posting it here on the mailing list.
>
> 	Ethan
>
>
>
>> Tatsuro
>
> ------------------------------------------------------------------------------
> 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
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Aw: Re: 5.2 rc2 tarball now available

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

> 2) Qt text boxes
> 
> I have modified the "test" command to show both the true bounding box
> as used by the current terminal (shaded rectangle) and the generic
> estimated bounding box used by the core program to reserve space for
> text in a plot layout.  It seems some Qt versions report an inaccurate
> bounding box width for some fonts (e.g. Qt 5.6.2 + DejaVu Sans).
> Nevertheless the terminal's internal bounding box is always more accurate
> than the generic estimated box.
> 
> Dan Sebald has pointed out that the Qt terminal and the cairo terminals
> differ in whether they increase the lower bound of the bounding box to
> allow for font descenders.   This is probably fixable but I consider it a
> minor issue.  

For the Windows terminal the new grey box in the "test" output is much
larger than the "estimated" bounding box. That should be fixed.

> 
> 3) caca terminal still EXPERIMENTAL?
> 
> I have libcaca 0.99 beta18.  The gnuplot caca terminal reports:
> set term caca driver list
>     x11 gl slang ncurses raw null
> 
> For me the x11 and gl options are usable although the x11 font handling
> has artifacts.  slang and ncurses spew garbage.  raw and null cause
> segfaults.  Most of the time changing a caca option causes gnuplot to exit.
> So yes, I think we need to warn that the caca terminal is still EXPERIMENTAL.

Moreover caca does currently not accept keyboard or mouse input in wgnuplot.
(But works using console mode gnuplot on Windows).
Btw. if ncurses or slang drivers work strongly depends on the terminal used.

> 
> 4) autoconfigure/compile on SunOS
> 
> Minor issues only.  The demo for building and linking plugins does
> not autoconfigure correction but can be built manually following instructions
> in the plugin demo Makefile.
> See also various notes attached to Bug #1821
> 
> 5) Unwanted inclusion of Type 3 fonts in cairo pdf output
> 
> The is Bug #1868.  No fix known.   Not a release-blocker.
> It would be great if someone would pursue this with the cairographics
> project maintainers.
> 
> 6) Any other known issues?
> 

The qt terminal on Windows has several known issues without known solution:

1. Slow start-up of first plot command:  On my system the first plot in a 
session is only shown with as much as 8 seconds delay. As indicated by Dan
 Sebald, this might (again) be related to fontconfig, see also Octave bug 
https://savannah.gnu.org/bugs/?45458 . We had that problem before with 
cairo/pango based terminals and first solved it by adding additional 
configuration files to the binary distribution (and later by not using 
fontconfig any more).
2. After space-raise-console, the first character which is input on the
 command line is lost.
3. replot-on-resize does not work as intended, see bug #1081.  We should
mention this in the release notes and recommend to turn that feature off
for now.

  Bastian

Re: Aw: Re: 5.2 rc2 tarball now available

[sfeam <sf...@us...>]

On Friday, 14 July 2017 06:34:19 Bastian Märkisch wrote:
> > 2) Qt text boxes
> > 
> > I have modified the "test" command to show both the true bounding box
> > as used by the current terminal (shaded rectangle) and the generic
> > estimated bounding box used by the core program to reserve space for
> > text in a plot layout.  It seems some Qt versions report an inaccurate
> > bounding box width for some fonts (e.g. Qt 5.6.2 + DejaVu Sans).
> > Nevertheless the terminal's internal bounding box is always more accurate
> > than the generic estimated box.
> > 
> > Dan Sebald has pointed out that the Qt terminal and the cairo terminals
> > differ in whether they increase the lower bound of the bounding box to
> > allow for font descenders.   This is probably fixable but I consider it a
> > minor issue.  
> 
> For the Windows terminal the new grey box in the "test" output is much
> larger than the "estimated" bounding box. That should be fixed.

Hmm.  The idea is that the "test" output is a diagnostic.  If you see problems
there then maybe something needs to be fixed in the terminal code.
The grey box is draw using essentially "set label boxed noborder fc 'gray'".
So if it is too large then it is a diagnostic that the textbox code draws
too-large boxes.  The estimated bounding box uses essentially
the same code as in boundary.c where the size of plot elements, titles,
key entries, etc are estimated.  If the the "test" output shows a poor fit
then it is a diagnostic that term->h_char and term->v_char are non-optimal. 
 
> > 
> > 3) caca terminal still EXPERIMENTAL?
> > 
> > I have libcaca 0.99 beta18.  The gnuplot caca terminal reports:
> > set term caca driver list
> >     x11 gl slang ncurses raw null
> > 
> > For me the x11 and gl options are usable although the x11 font handling
> > has artifacts.  slang and ncurses spew garbage.  raw and null cause
> > segfaults.  Most of the time changing a caca option causes gnuplot to exit.
> > So yes, I think we need to warn that the caca terminal is still EXPERIMENTAL.
> 
> Moreover caca does currently not accept keyboard or mouse input in wgnuplot.
> (But works using console mode gnuplot on Windows).
> Btw. if ncurses or slang drivers work strongly depends on the terminal used.

I know that's the theory but so far as I can tell it makes no difference at
all what the TERM environmental variable is set to.  That seems to indicate
that ncurses is not working the way it is supposed to.  I'm not sure whether
the problem is in ncurses or libcaca or caca.trm.   Or the terminal itself, 
come to think of it.  I have tried only xterm and konsole.

> > 
> > 4) autoconfigure/compile on SunOS
> > 
> > Minor issues only.  The demo for building and linking plugins does
> > not autoconfigure correction but can be built manually following instructions
> > in the plugin demo Makefile.
> > See also various notes attached to Bug #1821
> > 
> > 5) Unwanted inclusion of Type 3 fonts in cairo pdf output
> > 
> > The is Bug #1868.  No fix known.   Not a release-blocker.
> > It would be great if someone would pursue this with the cairographics
> > project maintainers.
> > 
> > 6) Any other known issues?
> > 
> 
> The qt terminal on Windows has several known issues without known solution:
> 
> 1. Slow start-up of first plot command:  On my system the first plot in a 
> session is only shown with as much as 8 seconds delay. As indicated by Dan
>  Sebald, this might (again) be related to fontconfig, see also Octave bug 
> https://savannah.gnu.org/bugs/?45458 . We had that problem before with 
> cairo/pango based terminals and first solved it by adding additional 
> configuration files to the binary distribution (and later by not using 
> fontconfig any more).
> 2. After space-raise-console, the first character which is input on the
>  command line is lost.

That sounds fixable.  Probably the same fix applied for "pause mouse".

I know I sound like a broken record, but I really hate space-raises-console. 
Surely there are better fixes that prevent focus-stealing proactively
rather than requiring you to grab it back by hitting an extra space key.

> 3. replot-on-resize does not work as intended, see bug #1081.  We should
> mention this in the release notes and recommend to turn that feature off
> for now.
> 
>   Bastian

OK. All of these should be mentioned in "Known Issues" in the
release notes.  Unless they are fixed of course.

	Ethan  

Aw: Re: 5.2 rc2 tarball now available

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

> Gesendet: Freitag, 14. Juli 2017 um 01:48 Uhr
> Von: "Ethan A Merritt via gnuplot-beta" <gnu...@li...>
> An: gnu...@li..., "Tatsuro MATSUOKA" <tma...@ya...>
> Betreff: Re: 5.2 rc2 tarball now available
>
> On Friday, 14 July, 2017 07:36:26 Tatsuro MATSUOKA wrote:
> > > 6) Any other known issues?
> > >
> > >     Ethan
> > >
> > This is not an issue but documentation problem for source distribution.
> > In source distribution, there is a file named "INSTALL".
> > It is well written but some parts are obsoleted or inadequate.
> > 
> > e.g.
> > 
> > 1. 
> > Unix, configure
> > ---------------
> >     
> > TERMLIBS="-lX11" ./configure
> > is required for wxwidgets but is not described
> > 
> > 2.
> > MS-Windows
> > ----------
> > 
> > There's no installer for gnuplot, so if you want a desktop link,
> > program manager group or an association of *.plt or *.gpl files to
> > wgnuplot, you'll have to do all that yourself.
> > 
> > The gnuplot for windows has installer now.
> > 
> > 
> > *********************
> > There are much points which are not up-to-date.
> 
> Good point.
> The FAQ, the man page, and the LaTeX tutorial are even more out of date.
> Contributions are welcome for all of these.
> 
> The same is true for the web site.
> The front page is not bad, but the linked pages are getting stale.
> 
> 
> > Is it better open a bug ticket for "INSTALL" being up-to-date?
> 
> A bug ticket is less useful than a patch containing new text.
> Or contribute new text by posting it here on the mailing list.
> 
> 	Ethan
> 
> 
> 
> > Tatsuro
> 

There's now a revision of the MS-Windows INSTALL section in CVS for 5.2.

  Bastian

Re: Aw: Re: 5.2 rc2 tarball now available

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

>>  > 2.
>>  > MS-Windows
>>  > ----------
>>  > 
>>  > There's no installer for gnuplot, so if you want a desktop link,
>>  > program manager group or an association of *.plt or *.gpl files to
>>  > wgnuplot, you'll have to do all that yourself.
>>  > 
>>  > The gnuplot for windows has installer now.
>>  > 
>>  > 
>>  > *********************
>>  > There are much points which are not up-to-date.
>> 
>> 
> 
> There's now a revision of the MS-Windows INSTALL section in CVS for 5.2.
> 
>   Bastian
> 

Thanks for change. 
INSTALL tells that now mingw toolkits are MinGW64/MSYS2 but not MINGW/MSYS.
I think that description of config/mingw/Makefile it to be changed in corresponding way.

Tatsuro