[config][1.33.1] MinGW improvements?
In the past few days I've been trying to get Boost using the upcoming STLport-5 release. In the process I've been checking Boost with the latest MinGW 3.4.2 release. And I found that some things have improved. In particular this change... =================================================================== RCS file: /cvsroot/boost/boost/boost/config/platform/win32.hpp,v retrieving revision 1.17 diff -u -r1.17 win32.hpp --- boost/config/platform/win32.hpp 25 Jul 2004 11:56:27 -0000 1.17 +++ boost/config/platform/win32.hpp 13 Sep 2005 05:54:47 -0000 @@ -24,6 +24,12 @@ # define __STDC_LIMIT_MACROS #endif +#if defined(__MINGW32__) && ((__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ >= 4))) +# define BOOST_HAS_MS_INT64 +# define BOOST_HAS_DIRENT_H +# define BOOST_HAS_UNISTD_H +#endif + // // Win32 will normally be using native Win32 threads, // but there is a pthread library avaliable as an option, =================================================================== I.e. it looks like, after running various tests of libraries that use that functionality, that not only are they present but functioning. OK to commit? ...To the 1.33.1 branch? It also looks like C99 wide char functions are also implemented and working. But I guess not enough for libstdc++ to work, but enough for STLport-5 to work. So with one exception, it should be possible to have MinGW+STLport support all wide char ops. The exceptions are that it doesn't have the non-reentrant wide char functions not in C99; AFAIK. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
+#if defined(__MINGW32__) && ((__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ >= 4)))
Oops, that should be: +#if defined(__MINGW32__) && (__GNUC__ == 3) && (__GNUC_MINOR__ >= 4) :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Simon Buchan wrote:
Rene Rivera wrote:
Rene Rivera wrote:
+#if defined(__MINGW32__) && ((__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ >= 4)))
Oops, that should be:
+#if defined(__MINGW32__) && (__GNUC__ == 3) && (__GNUC_MINOR__ >= 4)
What's wrong with GCC 4?
It doesn't exist in MinGW form yet, not even in beta. So it would be wrong of me to assume that it will have the same support. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Simon Buchan wrote:
Rene Rivera wrote:
Rene Rivera wrote:
+#if defined(__MINGW32__) && ((__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ >= 4)))
Oops, that should be:
+#if defined(__MINGW32__) && (__GNUC__ == 3) && (__GNUC_MINOR__ >= 4)
What's wrong with GCC 4?
It doesn't exist in MinGW form yet, not even in beta. So it would be wrong of me to assume that it will have the same support.
I compiled proper GNU GCC 4.0.0, and just installed over my MinGW precompiled package (after backing up, of course :D), so it just uses the same headers (exluding GNU's of course, no problems yet). I'm pretty sure the MS __int64 ext. is a GCC thing, not a MinGW thing. Im just guessing, though, since this is my work computer. Still, I _seriously_ doubt that the MinGW guys (and/or girls?) will pull any of those in future releases. PS: do I need to put line ends on these messages? Thunderbird auto flows to 80 columns, does it also add breaks?
Simon Buchan wrote:
Rene Rivera wrote:
Simon Buchan wrote:
What's wrong with GCC 4?
It doesn't exist in MinGW form yet, not even in beta. So it would be wrong of me to assume that it will have the same support.
I compiled proper GNU GCC 4.0.0, and just installed over my MinGW precompiled package (after backing up, of course :D), so it just uses the same headers (exluding GNU's of course, no problems yet). I'm pretty sure the MS __int64 ext. is a GCC thing, not a MinGW thing. Im just guessing, though, since this is my work computer. Still, I _seriously_ doubt that the MinGW guys (and/or girls?) will pull any of those in future releases.
Well one data point is enough in this case. Since I first leaned toward making the assumption in the first place. So back to the original patch. Doug? John? Bronek? Is it OK? I guess eventually I'll assume the answer is yes ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera <grafik.list@redshift-software.com>:
So back to the original patch. Doug? John? Bronek? Is it OK? I guess eventually I'll assume the answer is yes ;-)
well, update the trunk and see results ;-) I won't be able to do anything with mingw till I return from vacation. BTW: I played with idea of adding unofficial GCC 4.0.1 "mingw" to set of toolsets tested, but given that it has no support nor even distribution ... B.
+#if defined(__MINGW32__) && (__GNUC__ == 3) && (__GNUC_MINOR__ >= 4)
What's wrong with GCC 4?
It doesn't exist in MinGW form yet, not even in beta. So it would be wrong of me to assume that it will have the same support.
Maybe the right macros to use are one of: __MINGW32_VERSION Runtime version. __MINGW32_MAJOR_VERSION Runtime major version. __MINGW32_MINOR_VERSION Runtime minor version. __MINGW32_BUILD_DATE Runtime build date. Thoughts? John
John Maddock wrote:
+#if defined(__MINGW32__) && (__GNUC__ == 3) && (__GNUC_MINOR__ >= 4)
What's wrong with GCC 4?
It doesn't exist in MinGW form yet, not even in beta. So it would be wrong of me to assume that it will have the same support.
Maybe the right macros to use are one of:
__MINGW32_VERSION Runtime version. __MINGW32_MAJOR_VERSION Runtime major version. __MINGW32_MINOR_VERSION Runtime minor version. __MINGW32_BUILD_DATE Runtime build date.
Thoughts?
I wish :-) I stayed away from using them as those are only defined _after_ including an stdlib header. I.e. they aren't defined by the compiler but the runtime files. But if you think it's safe to assume that the runtime info is defined I'll use them. And I would guess similar changes should be made in other places? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
I wish :-) I stayed away from using them as those are only defined _after_ including an stdlib header. I.e. they aren't defined by the compiler but the runtime files. But if you think it's safe to assume that the runtime info is defined I'll use them. And I would guess similar changes should be made in other places?
Well by the time we get to the platform config headers at least one std lib header should have been included, but including <cstddef> would be enough to ensure that these get defined if think we should be doubly sure :-) John.
John Maddock wrote:
I wish :-) I stayed away from using them as those are only defined _after_ including an stdlib header.
Well by the time we get to the platform config headers at least one std lib header should have been included, but including <cstddef> would be enough to ensure that these get defined if think we should be doubly sure :-)
OK, not wanting to assume ;-) ... I changed it so that it includes <_mingw.h> which is the header that defines the runtime version macros. I also noticed that my initial investigation for msint64 was wrong so I took that out also. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
In the past few days I've been trying to get Boost using the upcoming STLport-5 release. In the process I've been checking Boost with the latest MinGW 3.4.2 release. And I found that some things have improved. In particular this change...
+#if defined(__MINGW32__) && ((__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ >= 4))) +# define BOOST_HAS_MS_INT64 +# define BOOST_HAS_DIRENT_H +# define BOOST_HAS_UNISTD_H +#endif
I.e. it looks like, after running various tests of libraries that use that functionality, that not only are they present but functioning.
OK to commit? ...To the 1.33.1 branch?
Double yes as far as I'm concerned.
It also looks like C99 wide char functions are also implemented and working. But I guess not enough for libstdc++ to work, but enough for STLport-5 to work. So with one exception, it should be possible to have MinGW+STLport support all wide char ops. The exceptions are that it doesn't have the non-reentrant wide char functions not in C99; AFAIK.
Excellent, I would assume that libstdc++3 will get wide character support once they decide to rebuild it (the C runtimes are a separate package that's independently upgradeable from the compiler). John.
In the past few days I've been trying to get Boost using the upcoming STLport-5 release. In the process I've been checking Boost with the latest MinGW 3.4.2 release. And I found that some things have improved. In particular this change...
If anyone is interested, I might be able to add Mingw + STLport5 to set of toolsets tested, but only after I return from vacation (Sep 26) B.
participants (4)
-
Bronek Kozicki -
John Maddock -
Rene Rivera -
Simon Buchan