> > > >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 believe Chuck was working on a mingw cross environment that resided on /opt/mingw. You could do similar and setup a wrapper with the ability to determine (based on the flags) which gcc to use. Dunno how useful that would be... Also, perhaps gcc2 could remain, but be named gcc2, etc. ? This way gcc 3.1 is the default, but people could optionally use gcc 2 if needs be. This is a real tough one, though. It's too bad that you can't pass a flag to gcc 3.1 to turn on v2 compatibility mode (like CC="gcc -v2") but I suppose that is too simplistic... One thing is for sure, it's almost as bad as the major number changes in glibc.
Cheers, Nicholas
