Menu
▾
▴
Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
|
From: Tatsuro M. <tma...@ya...> - 2015-06-12 03:07:38
|
----- Original Message -----
> From: Tatsuro MATSUOKA
> To: gnuplot-beta
> Cc:
> Date: 2015/6/11, Thu 19:42
> Subject: Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
>
> ----- Original Message -----
>
>> From: Tatsuro MATSUOKA
>> To: gnuplot-beta
>> Cc:
>> Date: 2015/3/3, Tue 16:16
>> Subject: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
>>
>> Hello
>>
>> I have tried to update gcc for windows build of gnuplot from ver. 4.9.0 to
>> 4.9.2.
>> Some observations happened for both 64 bit and 32 bit build.
>>
>>
>> Complier gcc-4.9.2-2 from MinGW-64 project
>> 64 bit : exception:seh, thread:win32
>> 32 bit : exception:dwarf2, thread:win32
>>
>> Good point
>>
>> I can built gd-2.1.1 flawlessly for both 64 bit and 32 bit platform.
>>
>>
>> Troubles ?
>> **********
>> 64 bit
>> **********
>> 1. I have met an error in compiling qt_conversion.cpp.
>>
>>
>> ../../src/qtterminal/qt_conversion.cpp:129:21: error: 'isnan' was
> not
>> declared in this scope
>>
>> The error above can be avoided using the following patch:
>>
>> --- src/qtterminal/qt_conversion.orig.cpp2014-04-21 03:46:32.000000000
> +0900
>> +++ src/qtterminal/qt_conversion.cpp2015-02-25 08:40:45.485861900 +0900
>> @@ -126,7 +126,7 @@
>> QRgb* line = (QRgb*)(qimage.scanLine(n));
>> for (int m = 0; m < M; m++)
>> {
>> -if (isnan(*image))
>> +if (std::isnan(*image))
>> {
>> image++;
>> *line++ = 0x00000000;
>>
>>
>> 2. For first plotting in wxt terminal, I see a waring message like an
> attached
>> file.
>> Here I write the text:
>>
>> You probably called setlocale() directly instead
>> of using wxLocale and now there is a
>> mismatch between C/C++ and Windows locale.
>> Things are going to break, please only change
>> locale by creating wxLocale objects to avoid this!
>>
>> The above message is written in wxWidgets-3.0.2/src/common/intl.cpp
>>
>> wxString wxLocale::GetInfo(wxLocaleInfo index, wxLocaleCategory cat)
>> {
>> const wxLanguageInfo * const
>> info = wxGetLocale() ?
> GetLanguageInfo(wxGetLocale()->GetLanguage())
>> : NULL;
>> if ( !info )
>> {
>> // wxSetLocale() hadn't been called yet of failed, hence CRT
> must be
>> // using "C" locale -- but check it to detect bugs that
> would
>> happen if
>> // this were not the case.
>> wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
>> wxS("You probably called setlocale() directly
> instead
>> ")
>> wxS("of using wxLocale and now there is a
> ")
>> wxS("mismatch between C/C++ and Windows
>> locale.\n")
>> wxS("Things are going to break, please only
> change
>> ")
>> wxS("locale by creating wxLocale objects to
> avoid
>> this!") );
>>
>>
>> // Return the hard coded values for C locale. This is really the
> right
>> // thing to do as there is no LCID we can use in the code below in
> this
>> // case, even LOCALE_INVARIANT is not quite the same as C locale
> (the
>> // only difference is that it uses %Y instead of %y in the date
> format
>> // but this difference is significant enough).
>>
>> The message appears for both wxWidgets-3.0.2 and wxWidgets-3.0.1.
>> However, I do not see the message building wxWidgets-3 by gcc-4.9.0.
>>
>> Any ideas to avoid the message? Otherwise, is the above problem of
> complier?
>>
>> ******
>> 32 bit
>> ******
>> gnuplot crashes by segmentation fault when one use cairo based terminals.
>>
>> Segmentation fault : g_utf8_validate gutf8.c:1634 on MinGW-64 32 bit
> gcc-4.9.2
>>
>> I have met a Segmentation fault at using gnuplot-5.1 built by myself on
>> windows.
>> The Segmentation fault seems to be related with the cairo based terminals.
>> (The cairo based terminals use libglib.)
>>
>> Compiler gcc-4.9.2 (MinGW-w64 32bit. dwarf, win32 thread).
>> Glib version : 2.42.1. Build from source.
>>
>> gdb message:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x6862318f in g_utf8_validate (str=0x2888a68 "-1", max_len=-1,
>> end=0xffffffff)
>> at ../../glib-2.42.1/glib/gutf8.c:1634
>> 1634 *end = p;
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x6862318f in g_utf8_validate (str=0xb28a68 "-1", max_len=-1,
>> end=0xffffffff)
>> at ../../glib-2.42.1/glib/gutf8.c:1634
>> 1634 *end = p;
>>
>>
>> Perhaps this is a bug of glib (2.42.1 and 2.33.14).
>>
>> I have filed the issue to the bug tracker of Gnome.
>>
>> https://bugzilla.gnome.org/show_bug.cgi?id=745485
>>
>>
>>
>> At this moment, I abandon the complier update. However, is the trouble 2
> for 64
>> bit case not a issue of gnuplot code?
>>
>> Regards
>>
>> Tatsuro
>
>
> *****************************************************************
> Hello
>
>> From above problems, I have been backed to gcc-4.9.0
> (For 32bit build suffers from Glib related seg-fault.)
>
>
> Recently I have update gcc-4.9.2 on MinGW project to release 3 and some
> libraries updated
> and re-try to build gnuplot using the tools.
>
> (The version of glib is updated to 2.44.1 from 2.42.1. )
>
> The segmentation fault for 32 bit build disappeared!!
>
> However, the problem became the same between 32 bit and 64 bit.
>
>> 1. I have met an error in compiling qt_conversion.cpp.
>>
>>
>> ../../src/qtterminal/qt_conversion.cpp:129:21: error: 'isnan' was
> not
>> declared in this scope
>>
>> The error above can be avoided using the following patch:
>>
>> --- src/qtterminal/qt_conversion.orig.cpp2014-04-21 03:46:32.000000000
> +0900
>> +++ src/qtterminal/qt_conversion.cpp2015-02-25 08:40:45.485861900 +0900
>> @@ -126,7 +126,7 @@
>> QRgb* line = (QRgb*)(qimage.scanLine(n));
>> for (int m = 0; m < M; m++)
>> {
>> -if (isnan(*image))
>> +if (std::isnan(*image))
>> {
>> image++;
>> *line++ = 0x00000000;
>>
>>
>> 2. For first plotting in wxt terminal, I see a waring message like an
> attached
>> file.
>> Here I write the text:
>>
>> You probably called setlocale() directly instead
>> of using wxLocale and now there is a
>> mismatch between C/C++ and Windows locale.
>> Things are going to break, please only change
>> locale by creating wxLocale objects to avoid this!
>>
>> The above message is written in wxWidgets-3.0.2/src/common/intl.cpp
>>
>> wxString wxLocale::GetInfo(wxLocaleInfo index, wxLocaleCategory cat)
>> {
>> const wxLanguageInfo * const
>> info = wxGetLocale() ?
> GetLanguageInfo(wxGetLocale()->GetLanguage())
>> : NULL;
>> if ( !info )
>> {
>> // wxSetLocale() hadn't been called yet of failed, hence CRT
> must be
>> // using "C" locale -- but check it to detect bugs that
> would
>> happen if
>> // this were not the case.
>> wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
>> wxS("You probably called setlocale() directly
> instead
>> ")
>> wxS("of using wxLocale and now there is a
> ")
>> wxS("mismatch between C/C++ and Windows
>> locale.\n")
>> wxS("Things are going to break, please only
> change
>> ")
>> wxS("locale by creating wxLocale objects to
> avoid
>> this!") );
>>
>>
>> // Return the hard coded values for C locale. This is really the
> right
>> // thing to do as there is no LCID we can use in the code below in
> this
>> // case, even LOCALE_INVARIANT is not quite the same as C locale
> (the
>> // only difference is that it uses %Y instead of %y in the date
> format
>> // but this difference is significant enough).
>>
>> The message appears for both wxWidgets-3.0.2 and wxWidgets-3.0.1.
>> However, I do not see the message building wxWidgets-3 by gcc-4.9.0.
>>
>> Any ideas to avoid the message? Otherwise, is the above problem of
> complier?
>
>
> For the problem 2, I temporally disabled to the ability to the message and built
> wx-3.0.2.
> (Just commented out the message part.)
> The treatment is not desirable.
> Could someone give me some hints?
>
> Tatsuro
Correction and clarification:
1. Complier gcc-4.9.2-3 from MinGW-64 project
64 bit : exception:seh, thread:win32
32 bit : exception:dwarf2, thread:win32
2. Glib is updated from 2.42.1 to 2.44.1.
(Glib related segmentation fault is disappeared.)
3. wxWidgets error dialog message
The comment out part of wxWidgets-3.0.2/src/common/intl.cpp is as follows:
--- intl.orig.cpp2014-10-07 06:33:44.000000000 +0900
+++ intl.cpp2015-02-25 16:24:12.462616200 +0900
@@ -1441,13 +1441,13 @@
// wxSetLocale() hadn't been called yet of failed, hence CRT must be
// using "C" locale -- but check it to detect bugs that would happen if
// this were not the case.
- wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
+/* wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
wxS("You probably called setlocale() directly instead ")
wxS("of using wxLocale and now there is a ")
wxS("mismatch between C/C++ and Windows locale.\n")
wxS("Things are going to break, please only change ")
wxS("locale by creating wxLocale objects to avoid this!") );
-
+*/
// Return the hard coded values for C locale. This is really the right
// thing to do as there is no LCID we can use in the code below in this
Without the above, gnuplot hangs when plotting on wxt terminal for 32 bit build.
(This is a correction.)
For 64 bit build, a MS-windows dialog which alert the message appears.
From the message, it can be said that CRT is not "C" locale.
Should I check the locale in wxt terminal codes and where should I check?
Tatsuro
|
