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