From:	noer AT cygnus DOT com (Geoffrey Noer)
Subject:	Re: #include <.string>
29 Dec 1998 15:52:43 -0800 :
Message-ID:	<19981229154533.34475.cygnus.cygwin32.developers@cygnus.com>
References:	<b0654f4e DOT 3688fbc8 AT aol DOT com>
Mime-Version:	1.0
To:	Mumit Khan <khan AT xraylith DOT wisc DOT edu>
Cc:	cygwin32-developers AT cygnus DOT com

On Tue, Dec 29, 1998 at 01:04:22PM -0600, Mumit Khan wrote:
[...]
> Yes, it's a problem with the -mno-cygwin flag and mingw32 alloc.h file,
> which gets included instead of STL alloc.h when compiling. Here's the
> fix:  Dump the mingw32 alloc.h, which is useless now, and even MS has
> dropped it in the newer VC releases (since 2.0?).
> 
>   $ cd /cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin32/include/mingw32]
>   $ mv alloc.h mingw_alloc.h
> 
> Now, it should work again. It doesn't happen with mingw32 egcs
> distribution since there the C++ include directory is searched *before*
> the C ones, but -iwithprefixbefore changes that order. 
> 
> This way of running GCC is subtly broken unfortunately, but since I have 
> no better solution at the moment, let's just dump alloc.h.

Should I do this in the main sources?  (Remove
include/mingw32/alloc.h?)  Sounds like it...

When you mention "This way of running GCC is subtly broken
unfortunately", are you referring to the Cygwin dependencies in
libstdc++ libraries in B20?  I'm going to see if it's ok to just
always build libstdc++ using -mno-cygwin and see what happens.  I
think that might solve this problem without our having to go to the
extreme of building it twice, once with Cygwin and once without it...

-- 
Geoffrey Noer
noer AT cygnus DOT com

- Raw text -