Mail Archives: cygwin-developers/1998/12/29/16:24:37
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<path/to/mingw/target/libs>, but that again
intrudes into the user's territory, and the order of -L<path> 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
- Raw text -