mingw and other gotchas in gcc 3.1

[egor duda]

Hi!

Monday, 24 June, 2002 Christopher Faylor cgf@redhat.com wrote:

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

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

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

This should be ok. There're also libstdc++ header files but,
fortunately, dirs are named differently (g++-3 for 2.95.3 and g++-v3
for 3.*). Can we make sure that this will remain so?

Btw, libstdc++ in gcc 3.* is configured so that classes in std::
namespace are not visible unless one specify std:: via 'using' or
explicitly. I feel this can be the problem that will make most noise.
Cygwin setup is just one example of program affected. I have a patch
that should work with both 2.95.3 and 3.*, and can post it if you're
interested.

One more problem is min() and max() macros in windef.h. They conflict
with min and max functions from <std_limits.h>. I've patched
std_limits.h to #undef min and #undef max, but applications which do
the following:

#include <windows.h>  // even if it's included non-directly
#include <limits>
...
x = max (a, b);

would break. I haven't found better solution for this, other than
mention it in release notes, though.

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

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

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

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

Do you think bin/ should contain cygwin->mingw cross-tools instead of
being link to i686-pc-cygwin?

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

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

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

libstdc++ seems to be a problem, no matter what was passed to
--enable-threads. I agree that libstdc++ (and libgcc in case of
--enable-threads=posix) stuff for mingw should be packaged
separately. I build them by hand and tested cygwin setup with them,
but i still have no automatic script to produce such package.

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

Have you created cygwin branch in gcc repository? I've seen your
question about it in gcc@gcc.gnu.org but somehow missed the final
resolution.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19