mingw and other gotchas in gcc 3.1

Earnie Boyd earnie_boyd@yahoo.com
Mon Jun 24 08:58:00 GMT 2002

Christopher Faylor wrote:
> 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?

I think the gcc2 idea should be acceptable.

> 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.

It should be i686-pc-mingw32.  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.  Otherwise
it's fine with me.

> 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,...

The sourceforge ftp directory is
ftp1.sourceforge.net/pub/sourceforge/mingw/ if you wish to take that
direction.  Or, Danny...

> 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?


More information about the Cygwin-apps mailing list