From: khan AT xraylith DOT wisc DOT edu (Mumit Khan) Subject: Re: #include <.string> 29 Dec 1998 16:24:37 -0800 Message-ID: References: <19981229154533 DOT 34475 AT cygnus DOT com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: Geoffrey Noer Cc: cygwin32-developers AT cygnus DOT com On Tue, 29 Dec 1998, Geoffrey Noer wrote: > > Should I do this in the main sources? (Remove > include/mingw32/alloc.h?) Sounds like it... Yes, not before you incorporate the original alloc.h into not-quite-as- non-standard-as-alloc.h malloc.h, which is what MS did to get out of the mess when STL became popular. I'll send you a patch this evening or tomorrow. This is going into the egcs-1.1.1 release for mingw/cygb20 out in a few days if the weather stays cold. > 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... Here's what I mean by "subtly broken": - Use of -iwithprefixbefore as opposed to -iwithprefix (ie., adding it to the main as opposed to the second include path). Unfortunately using -iwithprefix doesn't work in this case. This is not a big deal, but it can cause weird little problems when you're testing new versions of system includes, which most users don't. Since I'm probably the only one who gets bothered by this, so we can call this a non-issue and move on. - No analogous mechanism to supply a linker path! This is the tricky one. If there was a way to supply a new prefix for the linker search path, then we'll be all set with -mno-cygwin and -mcygwin, etc. And, as a bonus, we'll never have to think about multilib'ing again ;-) You can of course use a -L, but that again intrudes into the user's territory, and the order of -L args become important. Also, note that C++ links with libstdc++.a and libm.a, so we'll need to provide that mingw target as well. Fortunately, mignw libm.a is just an empty/dummy archive. Regards, Mumit