mingw and other gotchas in gcc 3.1

[Christopher Faylor <cgf at redhat dot com>]

I'm finishing up on the release of gcc 3.1 and I have a few gotchas that
I'd like to discuss:

1) I was going to take Red Hat's cue and release the new version of
   gcc as gcc3.  However, this will require manual deinstallation of
   gcc (2.95.3-whatever) so this is probably a bad thing.  Somehow, I
   just think that if we don't still make the older version of gcc
   available, there will be many "This used to build on gcc 2.95.3!!!"
   messages.

   So, maybe I should rename the old version to gcc2 or release a version
   of 2.95.3 that names the binaries (i686-pc-cygwin-gcc2) differently.
   Any thoughts?

2) I'm trying to remove most of the spec file magic that dealt with
   mingw and I think I've actually been pretty successful.  However,
   my new scheme relies on changing the machine name from i686-pc-cygwin
   to i686-pc-mingw.  That means that the new layout looks like this:

    /usr/i686-pc-mingw/:
    total 0
    lrwxrwxrwx    1 cgf      None          122 Jun 23 23:41 bin -> ../i686-pc-cygwin/bin
    lrwxrwxrwx    1 cgf      None          125 Jun 23 23:42 include -> /usr/include/mingw
    lrwxrwxrwx    1 cgf      None          113 Jun 23 23:42 lib -> /usr/lib/mingw

    /usr/lib/gcc-lib:
    total 0
    drwxr-xr-x    4 cgf      None            0 Dec 25  2000 i686-pc-cygwin
    lrwxrwxrwx    1 cgf      None          108 Jun 23 23:48 i686-pc-mingw -> i686-pc-cygwin

   Ideally, the include, lib stuff in /usr/i686-pc-mingw should not be a
   symbolic link but should, instead, be the actual directories that they
   reference.  However, coordinating this will be tricky.  I'm thinking that
   I should just add a postinstall script that will try to do the right thing
   if /usr/i686-pc-mingw doesn't have the right stuff.  However, I'd like to
   confirm with Earnie/Danny that this new layout makes sense.

   FWIW, I think this is the way I should have laid stuff out originally.

3) The above layout has a problem.  It works ok generating mingw binaries but,
   with gcc-3.1, I've configured things using --enable-threads=posix.  So, some
   binaries don't link successfully.  That means that the libgcc.a library is
   inappropriate for mingw.  So, the above directory layout can potentially
   become a little trickier since I'll need to build a libgcc.a (and libstdc++.a,
   I guess) for mingw.  This seems like a lot of duplication of effort, though,
   so maybe I'll try to figure out some way to download the bits that I need
   from sourceforge or something.  Or,...

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?

I've been toiling away at this for some time, so I'd appreciate any
useful suggestions.  My next hurdle is updating the gcc cygwin 3.1
branch with the latest changes in the gcc 3.1 branch.  I have to
automate that somehow.

cgf