On Windows XP SP2 32 bit with g++ 5.3.0 I get for __DATE__ and __TIME__ Nov 4 2016 and 7:2:35, respectively. Note that the leading zeros have been omitted.
Hmm. Not apparent with my cross-hosted mingw32-g++, but indeed, I can reproduce it with the crossed-native build, running on WinXP VM.
I suspect this may be a side effect of issue [#2309], so a recompile of the crossed-native compiler should likely fix it. Indeed, simply unpacking the attached replacement C++ package, over the top of my existing VM installation, seems to be sufficient to fix it for me; (curiously, it's the replacement of the C++ package which seems to be required, both for C++ and for C). Can you please confirm that it works likewise for you?
Sorry, this bug occured on a machine of friend of mine. I have no access to WinXP myself, and my friend went on a holiday, so he is unlikely to test it in the near future, sorry. In any case, I am glad you could reproduce it, and apparently fix it too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's unlikely that this is dependent on WinXP; should be apparent on any Windows version, with a MinGW installation of GCC-5.3.0 which was built against the buggy mingwrt-3.22 release, (as the current gcc-5.3.0-2 release was). Can you reproduce it on whatever version of Windows you are using?
Last edit: Keith Marshall 2016-11-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I meant I do not have access to any Windows at the moment or in the near future, sorry. I am on Linux but I occasionally help out friends who are unfortante enough to use Windows.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah! Okay, I also run Linux, with a mingw32 cross-gcc to build Windows binaries. As already noted this bug doesn't affect the cross-compiler itself, (it uses the native Linux printf()), but it does affect the crossed-native mingw32-gcc-5.3.0 which I built with it, while I had the buggy mingwrt-3.22 installed in the cross-compiler's library search path.
Thanks for raising the issue, anyway. I guess we'll just have to wait for your unfortunate friend to return from holiday, for the requested feed-back on effectiveness of the proposed solution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm. Not apparent with my cross-hosted
mingw32-g++
, but indeed, I can reproduce it with the crossed-native build, running on WinXP VM.I suspect this may be a side effect of issue [#2309], so a recompile of the crossed-native compiler should likely fix it. Indeed, simply unpacking the attached replacement C++ package, over the top of my existing VM installation, seems to be sufficient to fix it for me; (curiously, it's the replacement of the
C++
package which seems to be required, both forC++
and forC
). Can you please confirm that it works likewise for you?Related
Issues:
#2309Last edit: Keith Marshall 2016-11-05
Sorry, this bug occured on a machine of friend of mine. I have no access to WinXP myself, and my friend went on a holiday, so he is unlikely to test it in the near future, sorry. In any case, I am glad you could reproduce it, and apparently fix it too.
It's unlikely that this is dependent on WinXP; should be apparent on any Windows version, with a MinGW installation of GCC-5.3.0 which was built against the buggy
mingwrt-3.22
release, (as the current gcc-5.3.0-2 release was). Can you reproduce it on whatever version of Windows you are using?Last edit: Keith Marshall 2016-11-05
I meant I do not have access to any Windows at the moment or in the near future, sorry. I am on Linux but I occasionally help out friends who are unfortante enough to use Windows.
Ah! Okay, I also run Linux, with a mingw32 cross-gcc to build Windows binaries. As already noted this bug doesn't affect the cross-compiler itself, (it uses the native Linux
printf()
), but it does affect the crossed-nativemingw32-gcc-5.3.0
which I built with it, while I had the buggymingwrt-3.22
installed in the cross-compiler's library search path.Thanks for raising the issue, anyway. I guess we'll just have to wait for your unfortunate friend to return from holiday, for the requested feed-back on effectiveness of the proposed solution.
I believe this to have been fixed, in the interim. In the absence of any timely user response, I'm closing it as "out-of-date".