On Fri, 16 Nov 2007 14:09, [EMAIL PROTECTED] said: > Oh. I wasn't aware of an active regression here, but yes, that indeed > seems to be a known issue with 'upgrading' from 3.4 to current 4.x ...
I had already some complaints from folks (cross-)building gnupg and related stuff with the latest mingw. These where easy to fix, though. What troubles me more is that due to the flux in the mingw development stable working build systems can easily get in trouble. 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. 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. 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. 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. 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. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
