Menu
▾
▴
mingw-users
|
From: Clayton W. <min...@gm...> - 2016-09-18 21:31:52
|
When I do g++ -v I get:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/5.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-5.3.0/configure --build=x86_64-pc-linux-gnu
--host=mingw32 --prefix=/mingw --disable-win32-registry --target=mingw32
--with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada
--enable-static --enable-shared --enable-threads=posix --with-dwarf2
--disable-sjlj-exceptions --enable-version-specific-runtime-libs
--enable-libstdcxx-debug --with-tune=generic --enable-libgomp
--disable-libvtv --enable-nls
Thread model: posix
gcc version 5.3.0 (GCC)
I was testing a simple beginner source file:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, World!\n";
return 0;
}
Upon passing g++ hellotest.cpp -o hellotest.exe -std=c++11 through the
command prompt I am greeted with a wall of errors. Am I missing something?
Does MinGW not accept -std=c++11?
Sincerely,
Clayton Weaver
|
|
From: Keith M. <kei...@us...> - 2016-09-18 22:06:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/09/16 22:31, Clayton Weaver wrote: > Does MinGW [GCC-5.3.0] not accept -std=c++11? It does, but there are some incompatibilities in <stdlib.h> and (mostly) in <wchar.h>, from mingwrt-3.22.1. These should be fixed in the next release, but in the meantime, you might like to use the attached updates, (from my working hg-git clone). - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJX3w/iAAoJEMCtNsY0flo/BKMP/A3WJypYCcU1TdGgZMt8QzXu Jl1WWTDznLbTBdACtmP5aDwxZTTc5+O0kctAsNF8nycTFMMxo8nJV4sAEAGHGGLp UtT+T1K66N6At33MwK01TR6WRfR2/et6HbASs4wXqQI9zIjexHXro7XTaHAB5ge3 IkemqUJsSd71QLxoYRjjUW+EzjfwRkL0FAlvFqrQchFy1f5e5rFr9jblk0osuZvu z6peKyUUetHnl0liEqAKZerMOqV7xXCLfL0O6HNoTTk4YQrbMd33rkRrejfU0QyX ljBSFxf1d6xtbsGcJ4QD4m1rIcW5pc1RSw8aZk0PXCd0kFYJ4sSzkePgx0oc2b1O 4ENjJHmrJzv01rjt+cd5ncXE6Shhj3F2QKUitWjJGTOlSvYqgrFx2f7cVq/GC1WC o+P0ZWiWFJeljRnYr5qpfFiEmJ2GgP7yrNnJnFNTUrozQEXVvkAlYBN/yuSrndA+ pS5ffz+xt08e4TkC+Q0S7XwJuyWVV9wXC+1KdFk279jI40pnIyqAxtcAJnYIaA1c NwlF5Z7aQNejIkp7XhXIHz6L8n3UEQEXNFq7hK+CBBMw+uvTlim/UhANDwplmziS x1vM7hDEjv8ie1k1a0PTHNEFBrIK+UDOcGrreO+jkTsq6VelrjQ6+pKNu/7YI7jG 8PhpEqoCqI9Db9C1egbI =xSEj -----END PGP SIGNATURE----- |
|
From: Clayton W. <min...@gm...> - 2016-09-18 23:41:10
|
Thank you. I will share this if any other users elsewhere state the same issue I had. Here is hoping to the next release coming fast. Sincerely, Clayton Weaver On Sun, Sep 18, 2016 at 6:06 PM, Keith Marshall < kei...@us...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 18/09/16 22:31, Clayton Weaver wrote: > > Does MinGW [GCC-5.3.0] not accept -std=c++11? > > It does, but there are some incompatibilities in <stdlib.h> and > (mostly) in <wchar.h>, from mingwrt-3.22.1. These should be fixed > in the next release, but in the meantime, you might like to use > the attached updates, (from my working hg-git clone). > > - -- > Regards, > Keith. > > Public key available from keys.gnupg.net > Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.20 (GNU/Linux) > > iQIcBAEBAgAGBQJX3w/iAAoJEMCtNsY0flo/BKMP/A3WJypYCcU1TdGgZMt8QzXu > Jl1WWTDznLbTBdACtmP5aDwxZTTc5+O0kctAsNF8nycTFMMxo8nJV4sAEAGHGGLp > UtT+T1K66N6At33MwK01TR6WRfR2/et6HbASs4wXqQI9zIjexHXro7XTaHAB5ge3 > IkemqUJsSd71QLxoYRjjUW+EzjfwRkL0FAlvFqrQchFy1f5e5rFr9jblk0osuZvu > z6peKyUUetHnl0liEqAKZerMOqV7xXCLfL0O6HNoTTk4YQrbMd33rkRrejfU0QyX > ljBSFxf1d6xtbsGcJ4QD4m1rIcW5pc1RSw8aZk0PXCd0kFYJ4sSzkePgx0oc2b1O > 4ENjJHmrJzv01rjt+cd5ncXE6Shhj3F2QKUitWjJGTOlSvYqgrFx2f7cVq/GC1WC > o+P0ZWiWFJeljRnYr5qpfFiEmJ2GgP7yrNnJnFNTUrozQEXVvkAlYBN/yuSrndA+ > pS5ffz+xt08e4TkC+Q0S7XwJuyWVV9wXC+1KdFk279jI40pnIyqAxtcAJnYIaA1c > NwlF5Z7aQNejIkp7XhXIHz6L8n3UEQEXNFq7hK+CBBMw+uvTlim/UhANDwplmziS > x1vM7hDEjv8ie1k1a0PTHNEFBrIK+UDOcGrreO+jkTsq6VelrjQ6+pKNu/7YI7jG > 8PhpEqoCqI9Db9C1egbI > =xSEj > -----END PGP SIGNATURE----- > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
|
From: DAVENPORT, M. <mda...@co...> - 2016-09-20 17:37:33
|
You mentioned this is for std=C++11 Where do those headers go? Do they belong in include or C++/tr1? Or have I got it wrong? |
|
From: DAVENPORT, M. <mda...@co...> - 2016-09-20 18:48:17
|
Also as a related question, when is _NO_OLDNAMES defined? Does std=c++11 define that? I ask because allegro 5 programs don't compile when off_t is not defined, and sys/types.h only defines off_t when _NO_OLDNAMES is undefined. |
|
From: Keith M. <kei...@us...> - 2016-09-20 21:21:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/09/16 19:48, DAVENPORT, MARC wrote: > Also as a related question, when is _NO_OLDNAMES defined? Only when *you* choose to define it, (and why on earth would you do that, unless you've been brainwashed into the Microsoft mindset, to believe that POSIX type names are bad?) > Does std=c++11 define that? No. > I ask because allegro 5 programs don't compile when off_t is not > defined, and sys/types.h only defines off_t when _NO_OLDNAMES is > undefined. That's not what I see, in the current mingwrt-3.22.1 <sys/types.h>; off_t is a POSIX type name, and it is defined when _POSIX_C_SOURCE is defined. This is off-topic for this thread, but since you ask: to comply with POSIX, any application which depends on POSIX features is *supposed* to define _POSIX_C_SOURCE (or corresponding _XOPEN_SOURCE, for which _POSIX_C_SOURCE is implied) *before* it includes *any* header. FWIW, MinGW will implicitly define _POSIX_C_SOURCE, *unless* you choose to compile with any option which implies __STRICT_ANSI__; if you choose the latter course, then *you* must *explicitly* take care to define _POSIX_C_SOURCE, if you expect to use POSIX data types. I can only speculate that allegro 5 violates this POSIX.1 requirement. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJX4ahcAAoJEMCtNsY0flo/fLcP/jMw7nARvxwrGd4ynWht01n4 Xtug8C7bx4s63qPg45DN3NvJiARRQqoqYdePU1eBK0aW4ipbbKF+UJgSHEwe4k6+ Q4f3XxhjJS2TUPFn5ouI/YjCv+LvVot29pk5PaoA3yd6MYzUcrbMghsf3d48yYWN q/KXNEwR8pujFUdgd86hUafriMPILaEcca91J60cA4E24pamVkLHXzZp6eEB+/l9 9ywd+aetzRoaUIhDGhfTAf55+2LTtIwAivtKJ9RdGzBskSU75H8Xbyrbru9TI4VG VArMj4tSFOgBGZq5Rtf9lfH8JUvRLuTnL8RA8+g5nDdeftpj//xznUEcNz7GMhdh L6frnBLRg7SSn95xYR9gZ+MNEI3xQmCMjheagCbmRi5oHKm+5Z+wvI9tNBB1a0XG ynuwBT2ca2o8UY1kkE2gqylk4hK16xQFbSGPg2CNn5ZswBznTntE7D6wZCxaCY1b jG2rupV/wHmMhT/YaS5D3+tHorSipMOhzY8tUYrDnj+OHjXXPOra/rOKC7h1Rmst 20oDaD5L7urcFyapmLodZs0MiGF2L9MiTuaplDlLTeEXcR8ifnXxCAzHWVwfBLrg +visc24hJFsaMJxpejF80wCbF6TPAtIZj1/EPhasePgxmzU5oH45f+QPt3yuWOMZ NL6EPSJ9DX7+zwKcJMYb =7FFu -----END PGP SIGNATURE----- |
|
From: Keith M. <kei...@us...> - 2016-09-20 20:27:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/09/16 18:37, DAVENPORT, MARC wrote: > You mentioned this is for std=C++11 Only insofar as -std=c++11 requires C language includes specific to - -std=c99, but __STDC_VERSION__ doesn't appear to be defined to suit; (specifically, the conditions in <_mingw.h> for automatic definition of _ISOC99_SOURCE are not satisfied). > Where do those headers go? Do they belong in include or C++/tr1? In include; why would *any* C language header belong in the latter? Where are they, in your existing installation? They replace what is there already. > Or have I got it wrong? Yes indeed, you may have drawn a wrong inference. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJX4ZuNAAoJEMCtNsY0flo/UsAP/1cIMXPAzkJQfXT4SdI6Mv+T y1bdxXZf1f10PZL6agFWMLWS8th5CsJ13/ARHk1oE09R3YOWpkau6eXa3B5Xv/gc OrSRj+dWGl+KRbvGU3hjJRnWDtRXidh03aA1cy+NdOyoavgokqq/ozLIFkREhhL6 hFk4MM9vkFnAXeoZ4DGgQ6lVrKhB7K466p8LAsglwkzyw4zsoQhJGmmfDBxYwhDm IQ7AigjHU/5ttgF4AklTnXyhFBw+e2ywtwEZz0avgnEhoUL31WPsQE5eH+TNB0wB YlJwnbopbfGIpqQ5CJ3ZEVm+bEgBHlk3DqMPTmBD+qFGEQFZeEdw1BcTZR/O8qNr tf26Cwhn5Ccwxco/TCLYCdC3q2jd8/X+QHdEdtpI/xOJMDYsKPRWcTpnmA0Hxdmx xSWDKi8KM20MT3mV8Fjf3VuQrK0dtHHJhmM+mLVFHSvtl/WhzfoPTWDQJ4OvaWac V9gfHNKDI90hpX6hIfvetWepiO1hQ23/O5KcaWAl7+8I2uHgOo0aSi9Kr2hif7wm jXUri9GZObRBS4RIQJhQXIa1ujDrlXvN4/ts8WDe/CWaSvbu6q76yD0StP+lj6wg gWbXw3mSb3mMWtarHdfj8aWyu3UbpftnA0bS80PqKPQf1ONBa4esrkf5Vtae/E0j l9U8p3z/FN5fAeSz9d9B =vWFa -----END PGP SIGNATURE----- |
|
From: DAVENPORT, M. <mda...@co...> - 2016-09-20 20:39:23
|
On Tue, Sep 20, 2016 at 3:26 PM, Keith Marshall <keithmarshall@users. sourceforge.net> wrote: > > > Where do those headers go? Do they belong in include or C++/tr1? > > In include; why would *any* C language header belong in the latter? > Where are they, in your existing installation? They replace what is > there already. > > > Or have I got it wrong? > > Yes indeed, you may have drawn a wrong inference. > > - -- > Regards, > Keith. Okay, I'm slightly confused then. There are copies of stdlib.h and wchar.h in both of those directories. Why are there C headers in C++/tr1 if they don't belong there??? My confusion comes from not knowing whether tr1 is for the c++11 standard or not. Also, any idea on the _NO_OLDNAMES define in question from my previous reply? Can you tell me when that is defined? Is it defined when -std=c++11 is passed on the compile line? Please forgive my noobishness.... |
|
From: Keith M. <kei...@us...> - 2016-09-20 21:55:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/09/16 21:39, DAVENPORT, MARC wrote: > Okay, I'm slightly confused then. There are copies of stdlib.h and > wchar.h in both of those directories. Why are there C headers in > C++/tr1 if they don't belong there??? They aren't copies. All MinGW headers belong in include. Those in c++/<version>/tr1 are stubs, provided by the GCC project; if you want a definitive answer as to why they are there, you'll need to ask the GCC folks, (because I am not willing to speculate). > My confusion comes from not knowing whether tr1 is for the c++11 > standard or not. Strictly, no; it's a technical recommendation relating to an earlier version of the C++ standard, but pragmatically, any provisions of it which have been adopted should remain applicable in C++11. That said, I don't see the tr1 directory among the default include paths, for: $ mingw32-g++ -v -std=c++11 -c -xc++ /dev/null -o /dev/null (which isn't to say that there may not be any explicit references to it, from within headers in other directories, which do appear in the list of default include paths). - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJX4bA+AAoJEMCtNsY0flo/LBIQAKFcKzbUbWJjH48Ykec3lPA4 QFt3DUdPeGglLQI9ftCTDzKrr38vBFP4WpZcPaiMpU9HAkNdqg3C0Toxa93sPxpQ L9KrINltYSlMkfEFjJr5+ChfUrs/B/sgIaPjeGQ7CdhR9fZ38UXsngKM1qLE5Rqk SxkKwsRTmHKPTiAOdqyDqESZPFsvurPB+2qYZf1xHLvO8jH+vEmFLiLyii4JtM5w MHcV4zVLSg4yKfgF7c0sEzo/TQaKhpq89MMFHG/ZIYe7qwVj/ZaJOynYrbh0l0XC xxyu0riu1C3CUk8p+7ZULjwYfSMI3WLtXCAF++40OTvSvakzrBsV1Tfd8LLiYj8V 10Ha22DZgMvVBa262PLpewq9TKDjxEw0xeUSn0vGjnPkGFoOtulauzCKQOyksDjM uQzRdMkuF2t0eX8SdBBS4zXVTF2c3fX3KG4Tc+dsk4qSYSBpTbbZF6ttd0wSFXcS yDpE0GI4K+XKWeW49UCIPBvlaRspU8p3YVox07/kGi8L9uXUw5CWQ7NkCQldiZlP LKvVjeBIrkak4y+H9CjLQhwyQhn0BFBuSLWKQgMj/oV27gSmnAFaVEARZfp+OfWn IjNkXnNVDNkqdjyNRnTdb6oEOT53PAy3uNUogxwnfKOFjoP2H1a01oxrwRvYl2MQ j+qDLEZjpjArU2s2aWu9 =kGOT -----END PGP SIGNATURE----- |
|
From: Keith M. <kei...@us...> - 2016-09-21 11:08:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/09/16 00:41, Clayton Weaver wrote: > I will share this if any other users elsewhere state the same issue > I had. Here is hoping to the next release coming fast. I've just published mingwrt-3.22.2 and w32api-3.18.2 patch releases; they address these <stdlib.h> and <wchar.h> anomalies, in addition to a few pernickety C++11 warnings about spacing of combined sub-strings, within constructed literal strings, originating in <winnt.h> You may install these patch releases using mingw-get, after you have updated your local catalogue, when the FRS servers synchronize. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJX4mozAAoJEMCtNsY0flo/p/kQAKZ/Ebx2j6ePUP9RHstpa9ZE dRcb80iEWQTazE3vimEawQY42+f6GK3ohlOnQIYjIdVJ7etyvkF0TqHuXNAozria JZ4SOQ2EY/SDNNINkVEhXlI8JxslI0MHeRcsXmi/X/jgz3wbJqo7YOuldeAihWCi w4edNIbmPFeKNSqnPz9spQcTFx0QNEBeL/PHl+0SKQ9n51if/OuFentBQH5uo0p6 JDevY3xwuTm8zPv5nmk2HLleN3Smb0fpKZy3gBqgogxsGNNYH9A2wQtLnBM32h6T MYWvySZUbOO/1qaE0xGDUbj2xXmNDdPZs43moMiAZOPGzaZs0lv6pgY6MgC3NXgC 5LBgNahq7sueskByK7/9eh30k4A1RHWl1Xbxz9Xevdo3H149xyJ/sFOKNsMzxom4 1d2/E5rb/bqUUqOTRZQxOu77nG0UAGygqevfldkhzikq7z63prIdm7EBV4Qjuagc inMlrumQmdfIX1CYFzOtx2iaYBpUvjGeHdBAFJvepWRR804e++EtipQ9nrvvT9VO B/XZsMwKO2BFiyzyjcgOWQJSip7AbtOipbOV87A7LTupBYamXTEPwoHbQ2c8PyB4 xbqMLcs4T696k5qBQkiJMUAKK4m5g0nTpblq6OHQlknJh39pOpM+vvi8YUF1hjB4 YhlJNK1ZdvrPYAcklvWp =eeU8 -----END PGP SIGNATURE----- |
|
From: Clayton W. <min...@gm...> - 2016-10-09 06:09:19
|
I got the same errors with Allegro 5. Upon trying to compile an old A5 project with -std=c++11 I got the same errors mentioned about off_t and even got errors pertaining to cwchar.h stating ::wcscat, wcscmp, and several others were not declared. For Allegro 5, for now, it appears you have to pass -std=gnu++11 to compile or use a C++ library like SFML to make games or apps. On Wed, Sep 21, 2016 at 7:08 AM, Keith Marshall < kei...@us...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 19/09/16 00:41, Clayton Weaver wrote: > > I will share this if any other users elsewhere state the same issue > > I had. Here is hoping to the next release coming fast. > > I've just published mingwrt-3.22.2 and w32api-3.18.2 patch releases; > they address these <stdlib.h> and <wchar.h> anomalies, in addition to > a few pernickety C++11 warnings about spacing of combined sub-strings, > within constructed literal strings, originating in <winnt.h> > > You may install these patch releases using mingw-get, after you have > updated your local catalogue, when the FRS servers synchronize. > > - -- > Regards, > Keith. > > Public key available from keys.gnupg.net > Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.20 (GNU/Linux) > > iQIcBAEBAgAGBQJX4mozAAoJEMCtNsY0flo/p/kQAKZ/Ebx2j6ePUP9RHstpa9ZE > dRcb80iEWQTazE3vimEawQY42+f6GK3ohlOnQIYjIdVJ7etyvkF0TqHuXNAozria > JZ4SOQ2EY/SDNNINkVEhXlI8JxslI0MHeRcsXmi/X/jgz3wbJqo7YOuldeAihWCi > w4edNIbmPFeKNSqnPz9spQcTFx0QNEBeL/PHl+0SKQ9n51if/OuFentBQH5uo0p6 > JDevY3xwuTm8zPv5nmk2HLleN3Smb0fpKZy3gBqgogxsGNNYH9A2wQtLnBM32h6T > MYWvySZUbOO/1qaE0xGDUbj2xXmNDdPZs43moMiAZOPGzaZs0lv6pgY6MgC3NXgC > 5LBgNahq7sueskByK7/9eh30k4A1RHWl1Xbxz9Xevdo3H149xyJ/sFOKNsMzxom4 > 1d2/E5rb/bqUUqOTRZQxOu77nG0UAGygqevfldkhzikq7z63prIdm7EBV4Qjuagc > inMlrumQmdfIX1CYFzOtx2iaYBpUvjGeHdBAFJvepWRR804e++EtipQ9nrvvT9VO > B/XZsMwKO2BFiyzyjcgOWQJSip7AbtOipbOV87A7LTupBYamXTEPwoHbQ2c8PyB4 > xbqMLcs4T696k5qBQkiJMUAKK4m5g0nTpblq6OHQlknJh39pOpM+vvi8YUF1hjB4 > YhlJNK1ZdvrPYAcklvWp > =eeU8 > -----END PGP SIGNATURE----- > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
|
From: DAVENPORT, M. <mda...@co...> - 2016-10-09 16:59:24
|
On Sun, Oct 9, 2016 at 1:09 AM, Clayton Weaver <min...@gm...> wrote: > I got the same errors with Allegro 5. Upon trying to compile an old A5 > project with -std=c++11 I got the same errors mentioned about off_t and > even got errors pertaining to cwchar.h stating ::wcscat, wcscmp, and > several others were not declared. For Allegro 5, for now, it appears you > have to pass -std=gnu++11 to compile or use a C++ library like SFML to make > games or apps. > I can confirm this. My library build using A5 and C++11 does the same thing. There's also an error regarding _fsize_t being undefined. My library builds using -std=gnu++11 just fine. We're currently working on this in the allegro developers mailing list here : https://mail.gna.org/listinfo/allegro-developers As soon as I have more details, I will post again. |
|
From: DAVENPORT, M. <mda...@co...> - 2016-10-09 16:52:31
|
The error with _fsize_t appears to be due to an error with the way it is
included.
>From mingw/include/io.h lines 96-105 :
/* We must define _fsize_t, but some compilers (including GCC prior to
* version 4.0), may choke if we try to do so more than once...
*/
#if ! (defined _IO_H && defined _WCHAR_H)
/* ...so DO NOT define it during direct <io.h> inclusion, (i.e. _IO_H
* is defined), if <wchar.h> has already caused it to be defined, (i.e.
* _WCHAR_H is ALSO defined).
*/
typedef unsigned long _fsize_t;
#endif /* ! (_IO_H && _WCHAR_H) */
I searched mingw/include for _fsize_t and it is not declared in wchar.h. So
the problem may be including wchar.h before io.h which causes _fsize_t to
remain undefined.
>
The remaining errors are as follows :
||=== Build: Release in Allegro5_backend (compiler: GNU GCC Compiler) ===|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|177|error: '::wcscat' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|178|error: '::wcscmp' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|179|error: '::wcscoll'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|180|error: '::wcscpy' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|181|error: '::wcscspn'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|183|error: '::wcslen' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|184|error: '::wcsncat'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|185|error: '::wcsncmp'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|186|error: '::wcsncpy'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|188|error: '::wcsspn' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|193|error: '::wcstok' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|196|error: '::wcsxfrm'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|204|error: '::wcschr' has
not been declared|
c:\mingw\include\io.h|184|error: '_fsize_t' does not name a type|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|205|error: '::wcspbrk'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|206|error: '::wcsrchr'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|207|error: '::wcsstr' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\bits\char_traits.h|358|error:
'wcslen' was not declared in this scope|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar||In function 'wchar_t*
std::wcschr(wchar_t*, wchar_t)':|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|213|error: invalid
conversion from 'const wchar_t*' to 'wchar_t*' [-fpermissive]|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|212|note: initializing
argument 1 of 'wchar_t* std::wcschr(wchar_t*, wchar_t)'|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar||In function 'wchar_t*
std::wcspbrk(wchar_t*, const wchar_t*)':|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|217|error: invalid
conversion from 'const wchar_t*' to 'wchar_t*' [-fpermissive]|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|216|note: initializing
argument 1 of 'wchar_t* std::wcspbrk(wchar_t*, const wchar_t*)'|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar||In function 'wchar_t*
std::wcsrchr(wchar_t*, wchar_t)':|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|221|error: invalid
conversion from 'const wchar_t*' to 'wchar_t*' [-fpermissive]|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|220|note: initializing
argument 1 of 'wchar_t* std::wcsrchr(wchar_t*, wchar_t)'|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar||In function 'wchar_t*
std::wcsstr(wchar_t*, const wchar_t*)':|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|225|error: invalid
conversion from 'const wchar_t*' to 'wchar_t*' [-fpermissive]|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|224|note: initializing
argument 1 of 'wchar_t* std::wcsstr(wchar_t*, const wchar_t*)'|
|
|
From: Keith M. <kei...@us...> - 2016-10-12 22:55:32
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/10/16 17:27, DAVENPORT, MARC wrote: > Clayton Weaver <min...@gm...> wrote: >> I got the same errors with Allegro 5. Upon trying to compile an >> old A5 project with -std=c++11 I got the same errors mentioned >> about off_t and even got errors pertaining to cwchar.h stating >> ::wcscat, wcscmp, and several others were not declared. For >> Allegro 5, for now, it appears you have to pass -std=gnu++11 to >> compile or use a C++ library like SFML to make games or apps. > > I can confirm this. My library build using A5 and C++11 does the > same thing. There's also an error regarding _fsize_t being > undefined. My library builds using -std=gnu++11 just fine. I guess this should be expected (correct) behaviour. Neither off_t, nor _fsize_t, are strictly conforming ANSI types, so, if your project uses them, you shouldn't be compiling with an option which requires __STRICT_ANSI__ conformity checking, (as -std=c++11 does). To enable C++11 semantics, while still allowing for use of non-standard types, you should specify -std=gnu++11, (as you have found). - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJX/r9cAAoJEMCtNsY0flo/KVgQAKoMYXFGFjdUeXpSkIolAQGl LuIcsIoAhRvFAnWUXs6q5J99zJCSRrPKlmGeXhZOWEJX/MR1/iADPxupA3Pnhtsf ZjRaCjZ+kRbKcgrp9u6m3YUeWn+fGcO1vCME9x42q+gYP/bi+OiVqWXUJ8+V2/AS 3SMzUMdhrnzB+uup3V1X10sHlTu/1ky7ieH91P0lRsFtJMSooVYYBVr6yZPUmHhz GwLj+N0x5C+F5Ze56MXIcRzYEL7DGOGjf1TPT7kMgrVJ6vmXwadInpLrtmY9CwQ1 gxfMZGfj3UXCN/zrFct7i9z4ES3QkseIjqI3EqKSJ8DsWbNbuqb1iR6I6SiCZf2p tpEkAj3USqELNxEM3INzSh4077Nujzs3CYVQt8wJx7ras0YpDa3eCbUunqK2vZjs NY8P+fBDTzr3aJUzAJWdOUKkP/jg1n7UhEB1eyJik2ffKt01rrz+6QKNFQXzJF0a yOT3F5cppOZlUUjQMOfNe3sHdOc2ifrhHJuDMNMpgXuRiMcNgRCkLYBRUZO1GH46 DA08hBNRjeFnwzHqY5OvLqVtw03oy5LNfaYbGvttdwMaY/yHBrJzFp9+BCPHvXaS 8sPVSAXg2MmKkdShDEp+h3LL6Xrc8f0VOb+H3NV5KyeSS63btFeHNwRuOFfsJu9S PTDscLWhFyo2RIowg0t8 =V1lQ -----END PGP SIGNATURE----- |
|
From: Keith M. <kei...@us...> - 2016-10-13 18:46:30
Attachments:
sys-types.patch
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/10/16 23:55, Keith Marshall wrote: > On 09/10/16 17:27, DAVENPORT, MARC wrote: >> Clayton Weaver <min...@gm...> wrote: >>> I got the same errors with Allegro 5. Upon trying to compile an >>> old A5 project with -std=c++11 I got the same errors mentioned >>> about off_t and even got errors pertaining to cwchar.h stating >>> ::wcscat, wcscmp, and several others were not declared. For >>> Allegro 5, for now, it appears you have to pass -std=gnu++11 to >>> compile or use a C++ library like SFML to make games or apps. > >> I can confirm this. My library build using A5 and C++11 does the >> same thing. There's also an error regarding _fsize_t being >> undefined. My library builds using -std=gnu++11 just fine. > > I guess this should be expected (correct) behaviour. > > Neither off_t, nor _fsize_t, are strictly conforming ANSI types, > so, if your project uses them, you shouldn't be compiling with an > option which requires __STRICT_ANSI__ conformity checking, (as > -std=c++11 does). That said, if you've properly included non-ANSI <sys/types.h>, you should certainly get a typedef for Microsoft's ugly _off_t, and unless you've defined _NO_OLDNAMES, you would be justified in expecting that off_t would also be defined, irrespective of __STRICT_ANSI__. The attached patch addresses this anomaly. Similarly, if you've included non-ANSI header <io.h>, either directly or indirectly via any other non-ANSI header, then you might justifiably expect Microsoft's _fsize_t to be defined, once again irrespective of __STRICT_ANSI__; however, you should *not* expect it to be defined if <io.h> is included indirectly via an ANSI header, such as <wchar.h>, when __STRICT_ANSI__ is defined. In fact, this is a subtle bug in <io.h> itself: if <wchar.h> has already been included, before <io.h> is otherwise included, then the typedef of _fsize_t is assumed to have been seen already, and isn't repeated. This assumption is valid, if __STRICT_ANSI__ is *not* defined, but invalid when __STRICT_ANSI__ *is* defined. Thus, if you include <io.h> *before* <wchar.h>, you *will* get a typedef for _fsize_t, irrespective of __STRICT_ANSI__, but if you include <wchar.h> *before* <io.h>, (or any other non-ANSI header which includes <io.h>), then you will *not* get a typedef for _fsize_t. This is just wrong, and is also addressed in the attached patch. However, if you expect to get the _fsize_t typedef by including <wchar.h>, but without any other non-ANSI means of including <io.h>, then you will be disappointed if __STRICT_ANSI__ is defined; this is by design, and is correct behaviour. One final point: since you are getting errors pertaining to off_t not being defined, if you *have* included <sys/types.h>, then there *is* a bug in your own source code; you are violating the POSIX.1 requirement that you ensure that _POSIX_C_SOURCE is appropriately defined. MinGW will define this for you, but *only* when __STRICT_ANSI__ is *not* defined; if you compile with an option which implies __STRICT_ANSI__, then the onus falls on *you* to ensure that _POSIX_C_SOURCE is defined, *before* you include any POSIX.1 header, such as <sys/types.h>, to get access to POSIX.1 features, such as non-ANSI types, of which off_t is one. Compliance with this POSIX.1 requirement would have made off_t compilable, even with -std=c++11, and without the attached patch. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJX/9aFAAoJEMCtNsY0flo/urUP/3KQmrUItA1SsXK3EtoveDps jx6jTmeyvwT0zPAG5fJ5ITR0ytMNd7Dtb65ET/pehDPNNZRhUSrE2Lqd+uNqPXra HHACRscWVIOQLEuHFw4g7/VkUKZR1mYX36vN6q/TcHTz9f4BqoEttOIJDhh8o3LC 3dIHia2UTINPgGCZcBs2cgRz1kPozZeAVVIMlQoC63RPvzZQZ5MaUfrCNQWTaRdx cTQ/So9CBLKFYDHF5qswtZQIqIolC+f9JOwC8YshyyUWo/HjOlojHi8HiIbPy03c JVTXXZGbN1HIQISGdPwwr2bOXWiF10HVZgh7q7Mh57KSnfq0GVVthszFYbYX6a6k pj6gHR+QhLARD3r/4Wm11UGBtdl3We9Uga4rhG18k+9LxWpXufzK818BPQEesI8+ af/Cf1RuhucM5dTQYj0DVhNvb5j3AwdeQAenHHs5eDL7wsOxxhzcLSRya7Ilh/QG 7OZ/RPmwIJuD4eX9ph59TUmN4e7yWxNxuNTswpUdHWSWhFoOenDJhAJawC1oUO1f IPts4WqEjoETr2BJWDyjoW6IDMIyA/6sM0E5+Tuv1DJkOvhvLVuT9ZqLHc8bwYUs xwsrkHvDIBWvdTuENNxcnc7gnKUmvmnMk9jiAQG2uJFVFbJIUSGcTSB086PnByzL szOTmh95vFumVwEAJv5T =LAee -----END PGP SIGNATURE----- |
|
From: Keith M. <kei...@us...> - 2016-10-13 22:14:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/10/16 19:46, Keith Marshall wrote: [Re: missing off_t and _fsize_t typedefs, with -std=c++11] > This is just wrong, and is addressed in the attached patch. I've now published a mingwrt-3.22.3 patch release to address this issue. It should be installable via mingw-get, once the mirrors have caught up with the catalogue updates; you will need to update your local copy of the catalogue, before performing the installation, or package upgrade. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJYAAdVAAoJEMCtNsY0flo/Gr4P/RCLTAGgkBffL/SlWCmOtSmP 5/+rZIwgM1YuxxDHiIkkFquzMA3AlXO2U9mJj3w4p2iMIOcfsy/cDk1kQyfOu9Sn 6pbfUl8z+b7rAmuY7d0U/RRKcLDtmSA9ce8cw+DPxTYBPEFdt+Ts/lKRYQxnmlqt ZUGcUJZTeBcOvR3nBleRpMfn3akLfcZa5e7g6R8RHCco56ox9SUxnJr81T5DKyBn TjeYjG82fVahxSXoGxCVAPIgUGISXVbX0FeVufxBFkv+XOyBAQ1dRzAK6nY56qVp 4xRh4jR3oe9u460LyPozK65JivLZ+AggULwN5S4l057yOuwsGMpepcueVxuc4CXJ J77TFFbRDA0ixPFb0gVlXGnsFzxhieZ84eGlNt1fXJfCEbyOXFQE4VoOyM6KTLvc Ny1t7tNuajgA63YvirnwlOSUTVwsaLvL0fFeJXCgdkRZ/AD3wAXEf6pWbKrBR+Jn AXJK8+ac+Qq8+FyokuYPDFqOIkXUZlYt9EumTrijvnTSdZ/EVtmRHozNwxb8Q5hr V1jp4xdWK3dw/jZYWfmqvAynw3GZ4U52C07E2kNC27I9v5DHolBzbbwHKyQSsks0 ZU7nw7cUNJxYw5AMFywQk0jkuIm6vJ87idrf3uDQ/8fvGYN4FyUOdGNNB2PRwUQg LJblNfo31vQbv3Iye24i =sHRK -----END PGP SIGNATURE----- |
|
From: DAVENPORT, M. <mda...@co...> - 2016-10-16 22:39:44
|
On Thu, Oct 13, 2016 at 5:14 PM, Keith Marshall <
kei...@us...> wrote:
>
> I've now published a mingwrt-3.22.3 patch release to address this
> issue. It should be installable via mingw-get, once the mirrors have
> caught up with the catalogue updates; you will need to update your
> local copy of the catalogue, before performing the installation, or
> package upgrade.
>
> - --
> Regards,
> Keith.
Thanks Keith,
That patch fixes the aforementioned issues with off_t and _fsize_t.
However there are some other errors when compiling allegro programs with
the C++11 standard I mentioned before. I've narrowed down the cause to
#including <string.h> before #including <string>, as was happening with my
library. It causes all the undefined function errors listed below. It can
be fixed by including <string> *before* <string.h> or compiling as gnu++11.
Trying to compile this simple example program with the following command
(mingw32-g++ -Wall -O0 -std=c++11 -o mt.exe mt.cpp) causes the errors to
appear :
#include <string.h>
#include <string>
int main(int argc , char** argv) {
return 0;
}
The errors are as listed :
||=== Build: Release in Allegro5_backend (compiler: GNU GCC Compiler) ===|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|177|error: '::wcscat' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|178|error: '::wcscmp' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|179|error: '::wcscoll'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|180|error: '::wcscpy' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|181|error: '::wcscspn'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|183|error: '::wcslen' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|184|error: '::wcsncat'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|185|error: '::wcsncmp'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|186|error: '::wcsncpy'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|188|error: '::wcsspn' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|193|error: '::wcstok' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|196|error: '::wcsxfrm'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|204|error: '::wcschr' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|205|error: '::wcspbrk'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|206|error: '::wcsrchr'
has not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|207|error: '::wcsstr' has
not been declared|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar||In function 'wchar_t*
std::wcschr(wchar_t*, wchar_t)':|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|213|error: invalid
conversion from 'const wchar_t*' to 'wchar_t*' [-fpermissive]|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|212|note: initializing
argument 1 of 'wchar_t* std::wcschr(wchar_t*, wchar_t)'|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar||In function 'wchar_t*
std::wcspbrk(wchar_t*, const wchar_t*)':|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|217|error: invalid
conversion from 'const wchar_t*' to 'wchar_t*' [-fpermissive]|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|216|note: initializing
argument 1 of 'wchar_t* std::wcspbrk(wchar_t*, const wchar_t*)'|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar||In function 'wchar_t*
std::wcsrchr(wchar_t*, wchar_t)':|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|221|error: invalid
conversion from 'const wchar_t*' to 'wchar_t*' [-fpermissive]|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|220|note: initializing
argument 1 of 'wchar_t* std::wcsrchr(wchar_t*, wchar_t)'|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar||In function 'wchar_t*
std::wcsstr(wchar_t*, const wchar_t*)':|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|225|error: invalid
conversion from 'const wchar_t*' to 'wchar_t*' [-fpermissive]|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|224|note: initializing
argument 1 of 'wchar_t* std::wcsstr(wchar_t*, const wchar_t*)'|
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\bits\char_traits.h|358|error:
'wcslen' was not declared in this scope|
||=== Build finished: 21 error(s), 0 warning(s) (0 minute(s), 1 second(s))
===|
I haven't had time to determine the exact cause of this, but I hoped it
would be enough to give you to go on in order to make a fix. It also
happens if you include <cstring> before <string>.
Marc D.
|
|
From: Keith M. <kei...@us...> - 2016-10-17 17:06:36
Attachments:
wchar.h.patch
wchar.h
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 16/10/16 23:39, DAVENPORT, MARC wrote:
> That patch fixes the aforementioned issues with off_t and
> _fsize_t.
Good; thanks for confirming.
> However there are some other errors when compiling allegro
> programs with the C++11 standard I mentioned before. I've narrowed
> down the cause to #including <string.h> [or <cstring>] before
> #including <string>, as was happening with my library. It causes
> all the undefined function errors listed below. It can be fixed by
> including <string> *before* <string.h> or compiling as gnu++11.
That -std=gnu++11 vs. -std=c++11 is a good indicator that the problem
is somehow related to __STRICT_ANSI__ being defined.
> Trying to compile this simple example program with the following
> command (mingw32-g++ -Wall -O0 -std=c++11 -o mt.exe mt.cpp) causes
> the errors to appear :
>
> #include <string.h> #include <string>
>
> int main(int argc , char** argv) { return 0; }
Thanks. The first error message:
> c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwchar|177|error:
> '::wcscat' has not been declared|
points to the error being detected within <cwchar>, (but that isn't
where it actually lies), and indeed, your test case may be reduced to
no more than these two lines:
#include <cstring>
#include <cwchar>
I think I see where the actual problem lies; this condition, which I
see in <wchar.h>:
#if !(defined RC_INVOKED || (defined _WCHAR_H && defined _STRING_H))
assumes that the following block of code has already been processed,
if <string.h> has already been included, *before* <wchar.h> is parsed.
This assumption is valid, provided __STRICT_ANSI__ is *not* defined,
but becomes invalid in any __STRICT_ANSI__ context.
The attached patch should fix this, (or replace your existing copy of
c:/mingw/include/wchar.h with the attached alternative).
- --
Regards,
Keith.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQIcBAEBAgAGBQJYBQUIAAoJEMCtNsY0flo/ia4QAK90PrI8ioPXapwvg9qIkOU1
gz58fB+00XKjiLkQPZq3DowtVVnO0+XwLB6CGMzZW5SR7sntboe4DOgC7G9zZjaC
T7j5xNW4nQM6OpzW3ueazXaWWkgzaWCdHYC9i0zxwHvd0SYat5BC07n11fWVZnD9
rtZ3sM8G8nRImqUsfVt5ktd4eL+qrvJ6hoZ29i/G0MEolxMDDQfQaOD8ORWrNtsD
jK16ufZ2f9WfYI2vf9wSIrSWWaH+c7r8pRERNzC7CbXsbiv3wc4cQm87pTnA/tKf
+WIgs5CpYVTHlt8By6hKlk5MEhHjrFB8rWdYLS7GXb12IGuK3nEB6S2t/c1zZizF
LGFZCkYFp1CM8U4nA3IxiyI02OO5+NkbjoH/0Qs/PNPTKpG5cPXVq8xQ+pmDraeo
xkjOc2HeH4LHWOYYggnuPWecJeqGnT1HXiK2rrMPOn/oeWqZSstMTWEcIqwh/qO4
g9PFqajGSEVTZPdMvbxXKdFxwz1JOlTZHMKm4gYTz76vpQBxeT7/os12Xzgx2HcW
S1SByqmlcRVIUa1wQ+8wj1yjG10tQ5GUaftxNF6MyHp4FkJ8eKCHDSmT9jsVYbm4
SvR6SA4zPhtgIgLOEfzux21XsIe0vNW0V131mmyOvUi02SJRX97RINXpu2pS7zAx
IZCclxLsjQ1ILlA+0Zoe
=HdpO
-----END PGP SIGNATURE-----
|
|
From: Keith M. <kei...@us...> - 2016-10-17 17:37:00
Attachments:
wchar.h.patch
wchar.h
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/10/16 18:06, Keith Marshall wrote: > The attached patch should fix this, (or replace your existing copy > of c:/mingw/include/wchar.h with the attached alternative). Oops! Forget that previous patch; it breaks partial inclusion of <wchar.h> by <string.h>, when __STRICT_ANSI__ is *not* defined. Corrected version attached. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJYBQwqAAoJEMCtNsY0flo/fHEQAKdD7gficv5dUxrgj1kJUeMn r0wM6u/Q+GAVtBIBfY8b6OHxYolewJXjMkpQzZinMjXktCmoOKzANAiA5czDCk3a YtSCLOwxT4QtZv+dBLRm8eYKZwBgweAWwleyztPaZsg/cNl+9EUU96PLdbrYGUIW e6UNsUhyhdt6wGxKmVbJXV8CMkvP5Px3ujYDXqePTtxbAt0YnXv6NOLG7W8sKc6a V06/We0LSSXBafR0dLmZ1HsAxwIjOF0tfreal+moZEyJNJsOuioRZQhi9iLIqIBn 40JoA3225S42ZKQ3x57acxp+g+KKDMBk9ABRKc/3U7mK44Scoy+NGty5Rfgtf8zt f/WAajmpyqnUwqnFLZHHILONs4QbdKO4SVihxtk4XxVbaDiMT4u2xy0WLFPpCg+I 5oFaEcHHveKKDLfaJPFF6biMHp9xzlEI9lYoFU9to820Vqy+HMGP3fYnQghUq5+H 38DHeFiLdo7MaWjFNhz41/+jz0M0IZgfGHc14DhFWmX2+66eS9/W9t/ndjVd7AT5 jChqQGzuc7yna95TP1Xxy38gCQrW857fknHrT2fPIaRsZ+U/Pel0WwVVdYUVgDcQ sDLniHvlmnrG13O2fregH/FjC4K+UYthXDeCw90J9G+NHMth1krckoXoo4Sa8QeY pJD0rGvHsn9CsdX2T+jd =OBgf -----END PGP SIGNATURE----- |
|
From: Keith M. <kei...@us...> - 2016-10-18 19:40:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/10/16 18:36, Keith Marshall wrote: > On 17/10/16 18:06, Keith Marshall wrote: >> The attached patch should fix this, (or replace your existing >> copy of c:/mingw/include/wchar.h with the attached alternative). > > Oops! Forget that previous patch; it breaks partial inclusion of > <wchar.h> by <string.h>, when __STRICT_ANSI__ is *not* defined. > > Corrected version attached. Now included in patch release mingwrt-3.22.4, installable/upgradable via mingw-get (following local catalogue update). - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJYBnq1AAoJEMCtNsY0flo/cCYP+webpuLOTQ2YJASBPTSAz/GR dw7bDVSrkzOxjnOpVPIKDtonnobrh1h3iUkOhaB2bthdBR5AK6d7ierOQvPDgvo5 r6P4ezTF6/KjkDvkqn79sYCd7RS2FBZ1WE7Z4V2GLJ3Mld2ft/i+2dn//BYEDqG8 3IazQj9SJzQ0Zt9XfZs+V+JceX9kXbXHZqdvzNWsptUAvpfEmgyasML6xfb/SBkK 2nr+i2XJRrAUEr6mFOtV2ya0REDXGBkHLTqahnoVpOnZj7u/yM8aMzdzHwD2J56j eo5a1RaVXmbRGZ8m3R56nU4R2QCnC5DGDDfqZhZef+a5OpMiCn7xMGKO1rEkBAXv ucGj0vHSiV8c5gpKEHquGJ9mwC6C++FdQ8vUGSvWPFvsHIGOkXc6Jwpg937uZBXm /RVHh+NdZ6v188p0YiyanHGWzYvDO+063rTWB1ST5FtqsxjCayaZwFS0g5f8CnSF MOYb7gXuuwYPVSE8c3gNAsl12o0MmyqHDFEQ176oRRViEH6usNm6MQFDXbvXIyq5 UGqeoZegtIg4BExCvScV9GhyULqplc5rniHrjYubhawsTyo3On+eX3KlSWAxk37S z4HdTAbxDBufIoG+is29bDbctfoUCwsdJenTOOdHYHdv6ga84oIjfWGieLeVIbQp wtyCiR6Mg5svxqaTXqj7 =u0e9 -----END PGP SIGNATURE----- |
|
From: DAVENPORT, M. <mda...@co...> - 2016-10-17 19:05:20
|
That does the trick! Thanks a lot for your quick response!!! ;) I don't quite understand the logic of the line you used to fix the inclusion though (The comment confuses me) : #if defined _WCHAR_H && ! defined RC_INVOKED #if ! defined _STRING_H || defined __STRICT_ANSI__ /* ...such that these declarations are exposed when either _WCHAR_H, or * when _STRING_H is defined and __STRICT_ANSI__ is not, (since that would * indicate that these declarations have already been processed). As I understand it, the ! operator takes precedence over the ||, so logically it is (if STRING_H is not defined OR __STRICT_ANSI is defined, then include the function prototypes. Okay, wait I get it. If you apply the logical equivalent inverse of that you get (if STRING_H is defined AND __STRICT_ANSI is not). It's just confusing that the two different forms are logically equivalent but verbally different. I see what you're doing now. I just got confused. Forgetting my basic logical equivalencies. So, no worries, and thanks again! Marc On Mon, Oct 17, 2016 at 12:36 PM, Keith Marshall < kei...@us...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 17/10/16 18:06, Keith Marshall wrote: > > The attached patch should fix this, (or replace your existing copy > > of c:/mingw/include/wchar.h with the attached alternative). > > Oops! Forget that previous patch; it breaks partial inclusion of > <wchar.h> by <string.h>, when __STRICT_ANSI__ is *not* defined. > > Corrected version attached. > > - -- > Regards, > Keith. > > Public key available from keys.gnupg.net > Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.20 (GNU/Linux) > > iQIcBAEBAgAGBQJYBQwqAAoJEMCtNsY0flo/fHEQAKdD7gficv5dUxrgj1kJUeMn > r0wM6u/Q+GAVtBIBfY8b6OHxYolewJXjMkpQzZinMjXktCmoOKzANAiA5czDCk3a > YtSCLOwxT4QtZv+dBLRm8eYKZwBgweAWwleyztPaZsg/cNl+9EUU96PLdbrYGUIW > e6UNsUhyhdt6wGxKmVbJXV8CMkvP5Px3ujYDXqePTtxbAt0YnXv6NOLG7W8sKc6a > V06/We0LSSXBafR0dLmZ1HsAxwIjOF0tfreal+moZEyJNJsOuioRZQhi9iLIqIBn > 40JoA3225S42ZKQ3x57acxp+g+KKDMBk9ABRKc/3U7mK44Scoy+NGty5Rfgtf8zt > f/WAajmpyqnUwqnFLZHHILONs4QbdKO4SVihxtk4XxVbaDiMT4u2xy0WLFPpCg+I > 5oFaEcHHveKKDLfaJPFF6biMHp9xzlEI9lYoFU9to820Vqy+HMGP3fYnQghUq5+H > 38DHeFiLdo7MaWjFNhz41/+jz0M0IZgfGHc14DhFWmX2+66eS9/W9t/ndjVd7AT5 > jChqQGzuc7yna95TP1Xxy38gCQrW857fknHrT2fPIaRsZ+U/Pel0WwVVdYUVgDcQ > sDLniHvlmnrG13O2fregH/FjC4K+UYthXDeCw90J9G+NHMth1krckoXoo4Sa8QeY > pJD0rGvHsn9CsdX2T+jd > =OBgf > -----END PGP SIGNATURE----- > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
|
From: Keith M. <kei...@us...> - 2016-10-18 20:39:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/10/16 20:05, DAVENPORT, MARC wrote: [concerning partial inclusion guard logic in <wchar.h>] > I don't quite understand the logic of the line you used to fix the > inclusion though (The comment confuses me) : Inverse logic does tend to be confusing, especially when combining negated conditions. I've tried to make it clearer, in the published version, but basically the guarded code is always exposed the first time that part of <wchar.h> is read, but not if it is read a second time. For it to be read a second time, its first time *must* have been as a result of partial inclusion by <string.h>, which results in _STRING_H being defined, so if *both* _WCHAR_H and _STRING_H are defined: #if defined _WCHAR_H && defined _STRING_H then it is implicit that this is the second time of reading. However, if __STRICT_ANSI__ is defined, then the partial inclusion of <wchar.h> by <string.h> is suppressed, so _STRING_H may be defined *without* the assumed first reading of this code having occurred. Thus, to identify this case we need to check for the qualified sub-expression: #if defined _STRING_H && ! defined __STRICT_ANSI__ or, combining the two sub-expressions to identify a second reading: #if defined _WCHAR_H \ && (defined _STRING_H && ! defined __STRICT_ANSI__) Finally, we need to invert the logic, to *exclude* the guarded code on second reading, so we end up with[*]: #if ! (defined _WCHAR_H \ && (defined _STRING_H && ! defined __STRICT_ANSI__)) [*]: Yes, I know there are more parentheses there than may be strictly necessary; IMO, they should help to clarify the logical intent for the benefit of human readers. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJYBohsAAoJEMCtNsY0flo/uJoP/25UD29uueT4C2GGUf7nzO/n ASvV++Ll6XRk/eMg39qz1QkpXMdHw0PxJse+C1OnomfV4Z0jj+XsTGxDWSDNPrtp sr3wK1lAG/EZOYXSDWlhwhgdawLCqpL22Q4OhSrcB5El9koWen97ka+n1M7DCuIP qbvKN2PP9nNlUbOM7MZurqqflwMzH27eaU2kdBOX1p5+wizcV8PryDL1UIDf3K4t xcb+4tjEgSHJxOfxampak1hUMtLTi1Qjku1dLdadEZpJKJgsRl3HEdfCSOP0PN41 4eYcJxUNnuPr0yoQu9AZaS00o0JFFqNOnNXm4qYsiTpkDhfl3Ou8DnJQi6hKYrRQ /3QwVC2Z5SKWwjGcKIkF1TNxXLJe96yBIy4Zm01KaXWk90xveNppQBIeL/k1wxOo /VqiPgmERcYwYOUYxxNH1M+Y0BWnTPrmvkPy497lUzs3Uw7G4aKMh5VHUjnIJwLu 3iVYWCLZjWVUdUyGhTALToXZ20D/p/ICya6af2u13iRs45Q73w+Vg96tD/Koh+pL rEIOFoYEVgSxFsidsOtGr9hsViRMX9eSTm4Pl9Cz9DmBFvGEH4m8RtKCAyEWmlvt 0yTRzVUV4WDz2HpvfKIIRXp+FTDJY8jI5kfzAzZ0iVJMjWgOplXuv59VvlZF0xGZ 0/p8PIyZhvy9sB12lOXi =K/+h -----END PGP SIGNATURE----- |
|
From: DAVENPORT, M. <mda...@co...> - 2016-10-18 22:19:04
|
On Tue, Oct 18, 2016 at 3:39 PM, Keith Marshall < kei...@us...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 17/10/16 20:05, DAVENPORT, MARC wrote: > [concerning partial inclusion guard logic in <wchar.h>] > > I don't quite understand the logic of the line you used to fix the > > inclusion though (The comment confuses me) : > > Inverse logic does tend to be confusing, especially when combining > negated conditions. I've tried to make it clearer, in the published > version, but basically the guarded code is always exposed the first > time that part of <wchar.h> is read, but not if it is read a second > time. For it to be read a second time, its first time *must* have > been as a result of partial inclusion by <string.h>, which results > in _STRING_H being defined, so if *both* _WCHAR_H and _STRING_H are > defined: > > #if defined _WCHAR_H && defined _STRING_H > > then it is implicit that this is the second time of reading. However, > if __STRICT_ANSI__ is defined, then the partial inclusion of <wchar.h> > by <string.h> is suppressed, so _STRING_H may be defined *without* the > assumed first reading of this code having occurred. Thus, to identify > this case we need to check for the qualified sub-expression: > > #if defined _STRING_H && ! defined __STRICT_ANSI__ > > or, combining the two sub-expressions to identify a second reading: > > #if defined _WCHAR_H \ > && (defined _STRING_H && ! defined __STRICT_ANSI__) > > Finally, we need to invert the logic, to *exclude* the guarded code on > second reading, so we end up with[*]: > > #if ! (defined _WCHAR_H \ > && (defined _STRING_H && ! defined __STRICT_ANSI__)) > > [*]: Yes, I know there are more parentheses there than may be strictly > necessary; IMO, they should help to clarify the logical intent for the > benefit of human readers. > Thanks for the explanation. If I remember my logic correctly, it follows that there is an equivalent form using associativity and DeMorgan's laws. !(A && (B && !C)) == Use Associativity !((A && B) && !C) == Substitute D for (A && B) !(D && !C) == Use DeMorgan's law to distribute NOT !D || C == Substitute (A && B) for D !(A && B) || C == Use DeMorgan's law to distribute NOT ----------------------------------- !A || !B || C This would mean that the equivalent expression would be : if !defined _WCHAR_H || !defined _STRING_H || defined __STRICT_ANSI However, in the header wchar.h, _WCHAR_H is always defined so the expression would actually simplify to : if !defined _STRING_H || defined __STRICT_ANSI I think my logic is correct. Does that make sense? This way it will be included if _STRING_H is not defined (in the case of wchar.h being included first) or if __STRICT_ANSI is defined, in which case the first reading would have been suppressed. Hopefully I'm being helpful and not confusing the issue. In any case I appreciate the fix. Marc D. |
|
From: Keith M. <kei...@us...> - 2016-10-19 08:11:53
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/10/16 23:18, DAVENPORT, MARC wrote: > However, in the header wchar.h, _WCHAR_H is always defined ... No, it isn't. If <wchar.h> is being read for the first time, as an adjunct to <string.h>, then __STRING_H_SOURCED__ is defined, and only that part of <wchar.h> which declares the (non-standard) Microsoft specific pollution of the <string.h> namespace is exposed; the definition of _WCHAR_H is not exposed, in that case. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJYByrBAAoJEMCtNsY0flo/9boQAMtE/0XSKtWEy1phuEIl45pv aMrdF34JETHXs+C82zMIUQAlxDW13pZkntoLfNa6jv0evLpnqiDzFpGOsih7C119 Dw10shcWTCCDqtXe5YxWDbKaXd5j2agrzT3fhvaS4f/N/6slf1aCCcnBWeSRqWPh NWiLfLNax7NqjXByi3rUm+m26LMxsO0y9lrdHsF2xSPJSK1AZitT2DX5lU9A2U+E U02727EFh7d+FyvpZwPLoTwWlsZf9wTGkSvI2UEZWMUktjVovD9/z9iat05+uGAr 1tL5p5qyY4Ke28z2ZbrkBY7V18+qE2wtnhwqBpEBdeiROhavIUONPGBlZsmZLEoB nSonpmkC9p11axMVCbkVKtpN3tUaIuFBo9jMQFD5oofwHxxDKfCIs58l6ACIjVIS a58SWyMLbJJG8+ZCeUnASPTEnkD6Z5dZVMDrWQXyreLzrludPS1EjdBeC6afeXA5 3PkwwgKBJGXRR4hhhS5/jRO2GWwvs0wQ1ZOQnY6+YXQdnT356LtJft7uejpr06wn zeM6rVj8UTXSgSAI7+grSKA4+IVI9I0sUX76M1k4LgQlXUZgm8nqMIdfeTIXsX/m U/yEXcuATn6ilw+O+TBYM7WFJqoPWdg0TlgjcHvODVKncgHsi0yyOzaP6Epegpsj WNvul4AUbhweloCH2gCf =hD27 -----END PGP SIGNATURE----- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X