On Mon, May 07, 2007 at 07:47:01PM +0200, Paolo Carlini wrote: > Daniel Jacobowitz wrote: > > > The failing command is trying to compile the PCH. This means that > > we're including a large number of libstdc++ headers in a row. One of > > the first ones pulls in c++config.h, which has #undef max; but so far, > > nothing has included <windows.h>. Later, something includes > > gthr-default.h; on this platform that pulls in <windows.h>, which > > eventually #define's min. Then later we get <limits>, which now sees > > the definition. > > > I see, but I still don't get why this is worse than time ago, when the undefs > where placed in the middle of stl_algobase.h and nowhere else. Do you?
I am just guessing, but I suspect that something before the middle of stl_algobase.h caused <windows.h> to be included. Here's the ugly patch I'm using right now to get past this: @@ -226,6 +226,10 @@ _GLIBCXX_END_NAMESPACE #define __N(msgid) (msgid) // For example, <windows.h> is known to #define min and max as macros... +// HACK +#ifdef __MSVCRT__ +# include <windows.h> +#endif #undef min #undef max Unfortunately, libstdc++ uses ioctl if FIONREAD is defined, but mingw defines FIONREAD without defining ioctl (there's "ioctlsocket", but it doesn't work on files). Something now causes the definition of FIONREAD to be visible to basic_file_stdio.cc. So I needed another hack there too. > No idea, absolutely, I don't know the source directory. But, again, I don't > see, in general, why things are worse than some time ago. In the libstdc++-v3 > directory nothing changed about ctype_base.h lately, it doesn't include > anything, and is only included after <cctype>. That's a good question. I don't know either; maybe combined tree builds never worked? Anyway, I did get it built eventually. But I'm stumped as to why I had to maul the sources to get it to work. Here's hoping someone else knows what's going on with this port. -- Daniel Jacobowitz CodeSourcery
