Re: mingw and other gotchas in gcc 3.1

[Christopher Faylor <cgf at redhat dot com>]

On Mon, Jun 24, 2002 at 10:44:08AM -0400, Earnie Boyd wrote:
>>FWIW, I think this is the way I should have laid stuff out originally.
>
>It should be i686-pc-mingw32.

I thought I asked about the mingw32 -> mingw transition a while ago and you
were fine with it.

I've never actually understood the obsession with including the word size
in the product name.  It's like adding "new" to your package name.  As soon
as you do that, you guarantee that a package named new will be older than
some other package at some point.

I understand the genesis of packages like w32api and mingw32 but I think the
32 is really dating both packages.

However, I can see that configure scripts seem to be assuming the 32 so,
while it makes no difference to this application, I suppose I should be
consistent with what configure creates.

>You also may wish the target to be stated only as mingw32 instead of
>i686-pc-mingw32 in order to be consistent with the MinGW version and to
>ward off confusion in the list.

There is already a i686-pc-cygwin directory.  i686-pc-mingw* is nicely
compatible with that.

>> 4) Since mingw is becoming so logically separated from gcc, it is possible that
>>    it could become a separate package.  So, if "someone" was willing to supply
>>    a gcc-mingw package, it would actually be helpful.  I don't think I could
>>    stand the pain of making this optional, so the gcc package would rely on
>>    the gcc-mingw package rather than the other way around. This would allow
>>    updating libgcc.a and libstdc++.a without requiring a new release of gcc.
>>    Hmm.  I wonder if I should break libstdc++.a out of the gcc package.  Urgh.
>>    Any suckers (cough) want to contribute a separate package?
>> 
>
>Or would a --host=cygwin --build=cygwin --target=mingw be better for the
>gcc-mingw cygwin package?

I can't think of a reason why the "natively" built mingw stuff shouldn't work
fine.

cgf