Hi Werner, On Fri, Nov 16, 2007 at 07:26:48PM +0100, Werner Koch wrote: > I had already some complaints from folks (cross-)building gnupg and > related stuff with the latest mingw. These where easy to fix, though.
Were these problems with the compiler being more strict, or with it being more buggy? They are both inconvenient but they aren't equally terrible things ;) > What troubles me more is that due to the flux in the mingw development > stable working build systems can easily get in trouble. We had 21 months between the 3.4.5 release and the current 4.2.1 candidate, so I wouldn't quite describe the pace of change as frantic. Making it available now gives us plenty of time to assess its viability for Lenny. > For example > with Gpg4win we build quite a lot of software for Windows on Debian all > fully automated. When doing a new release we can't do thorough tests on > all software to cacth errors introduced by a new toolchain. I can, and do, quite sympathise with this problem just the same though. Unfortunately, neither you nor I can really stop it -- if the new toolchain is out, some user somewhere is going to try to use it, and if it doesn't work, you are probably going to hear from them about it. So in some respects the best thing I can do is make it easy for you to grab the new toolchain, so when that happens you have the tools to fix it quickly... > For us it > is far better to go with a system we know well (mingw from Etch as of > now) than to have new compiler or library features. Windows is a > platform which does not change often and is anyway only available for > ia32 and thus there are no advantages with a new compiler. Yes, the linux kernel team have long done this. They recommend a known specific compiler and other people ignore them and find any bugs that shake out. But for production use, bet on the recommended compiler. > I am not aware of any bug or missing feature in the version which is in > Etch. We can do any kind of software: plain exe, standard DLLs, > extension DLLs. All in C and C++ without any problem. We had quite a few people nag for it to be updated, and I know of at least one package in the distro that has serious bugs which are fixed by having it. gcc4.2 in general seems to have a few more rough edges than its predecessors have lead us to expect, but this is the first functionally significant regressive issue I am aware of to date. > Having mingw in > Debian make my life much easier as I am not anymore forced to maintain > my own W32 cross-compiling chains which I did for many years. Thanks, > Ron. > > Having said this, I'd would very much appreciate if the current > mingw/etch version could be frozen and kept as is. It is frozen, its just frozen in etch. If you can't just install those and have them work, and you really need them, then it shouldn't be too hard to maintain a 'forward port' in some public location. > If there is a need > for new version of mingw there is still the option to create a new > package for it - much like we do with the standard gcc. We've never really had much need for multiple versions installed together before with this one... previously the newer versions were always a clear upgrade path by the time we settled on one for the next Debian release. So the package structure isn't quite suitable for that as is, but it should be possible to fix that too... This is a slightly separate case though, of people who need both compilers on the same machine. If you just need one or the other, you should be able to replace the sid compiler with the etch one without too much trouble. Since mixing the output of them together is probably Bad, this may not really be a terrible thing either ... Are you still actually having problems with 4.2.1, or just hoping (as we all do) that they won't be repeated too often? Cheers, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
