> Date: Wed, 10 Apr 2013 16:19:16 -0400
> From: Earnie Boyd <earnie@...>
> 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 and then follow
> the installation steps below beginning with the update step.
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
. 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
. 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
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.
Last, but not least: thanks for developing MinGW!