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
