From: Eli Z. <el...@gn...> - 2013-04-11 16:59:16
|
> Date: Wed, 10 Apr 2013 16:19:16 -0400 > From: Earnie Boyd <ea...@us...> > > On Tue, Apr 9, 2013 at 6:23 PM, Earnie Boyd wrote: > > I am pleased to announce a release candidate for the up and coming mingwrt-4.0 > > and w32api-4.0 release. The process to test is convoluted and messy in order > > to keep related package data for mingw-get in sync. However, we are > > releasing this candidate package so that you may be involved with > > testing it. > > > > This first release had a packaging error and did not deliver the > library object files. I have correct that issue in the rc-2 release. > The commands are the same. If you installed the first release > candidate then please execute the uninstall step[5] and then follow > the installation steps below beginning with the update step[2]. Thank you! It is very good to know a new major release is around the corner. I see that it solves the nasty Windows 7 problem with quoted wildcards (something which IMO is definitely NEWS-worthy, but I didn't find it there). However, I was extremely disappointed, to say the least, to read this part of NEWS: We have an ABI incompatibility due to a reworking of the dirent.c which provides opendir() and friends. You will need to rebuild all libraries to that use these functions. Can you tell what are the advantages that justify this ABI incompatibility? NEWS only hints about "Performance improvements in libmingwex.a dirent.c code." Is this the only reason? If so, is there any chance to convince you not to make this change? I apologize in advance if what I write below is based on some basic misunderstanding, and the problems I envision don't really exist. But if I'm right, there's any number of nasty problems this change will cause. Here's what comes to mind: . You say "rebuild all libraries that use these functions". This is only practical if one builds all of their libraries. (Even then it's a nuisance, and one could be in for some non-trivial amount of work: e.g., some old library might not even compile out of the box with a newer compiler that is now required. Also, do we really have an easy way of telling which libraries use these functions?) . I expect most MinGW users not to build the libraries they use to build programs. I think it's quite common on Windows to download precompiled binaries of many libraries. All of those libraries will immediately become unusable with the new MinGW runtime. Now users will have to determine which ones use these functions, and then search for precompiled binaries that were built with the right mingwrt. What are the chances that the site which offers some library will explicitly tell which version of the runtime they were built with? . But it is not enough to find and install newer versions of the libraries. During the transition period (which could take many months if not several years), there will be packages that will depend on the old runtime and others that will depend on the new one. That means users will have to keep 2 versions of libraries that call the dirent functions, and futz with their PATH so that these versions don't conflict. Having 2 versions of the same DLL will then risk that the wrong one is detected by some configure script, with predictably unpleasant results. Welcome back to the DLL hell! . People that build libraries and upload them for others to use (such as yours truly) are also in for a bumpy ride: How can I make my users happy, regardless of the runtime they have installed? The only way is for me to have 2 MinGW installations, which is a PITA to manage and also error prone. . The MinGW site will need a complete recompile of every binary package, and also to clearly mark each old and new package with the runtime version it is compatible with. Until this is done, downloading from the MinGW site will be unsafe: it could break perfectly good packages you already have installed. And what about those packages whose contributors or maintainers are no longer available? Again, I apologize if I'm missing something that makes most or all of the above irrelevant. I will be the first to be happy to learn that these problems are not real. But if they _are_ real, I really think we will be much better off without this ABI incompatibility, even if we have to live with a slightly less efficient functions. At the very least let's have some reasonably practical optional way to build programs with the new runtime without breaking the ABI. Please? Last, but not least: thanks for developing MinGW! |