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: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Mumit Khan 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