From: Eli Z. <el...@gn...> - 2012-05-17 16:56:15
|
The new startup code in the snapshot of MinGW runtime 3.21 uses 'glob' to expand wildcards in the command-line arguments. The immediate side effect of this is that every MinGW program has 'glob' pulled into it. If a MinGW programs includes a different implementation of 'glob', it might now be in trouble. A case in point is the MinGW build of GNU Make. It brings with it the GNU implementation of 'glob', and compiles it into make.exe. The result is that the MinGW startup code uses the GNU implementation of 'glob', and so make.exe globs its command-line argument in a non-default fashion (in particular, backslashes are not supported as directory separators). One could make a point that a program should probe the runtime and use the library implementation of 'glob' if it exists. That might be true in an ideal world, but is tricky in practice, since MinGW didn't have 'glob' until now, and thus we can expect packages to assume that, and bring 'glob' from elsewhere. Specifically for Make, (a) the official way of building it natively with MinGW is by running a batch file that doesn't probe the runtime at all, and (b) even if you do run the configure script, it decides not to use the library implementation, because (for some reason) it insists on GNU 'glob', and thus requires in its test program the headers features.h and fnmatch.h which MinGW doesn't have. A similar problem happens with 'opendir', 'readdir', etc. that 'glob' uses. In fact, the problem here is even more serious, since v3.21 changes the layout of 'struct dirent' in an incompatible fashion. The result was that command-line wildcard expansion in Emacs became broken, because (gasp!) Emacs has its own replacements for these functions (to support MSVC builds, among other reasons), and the layout of 'struct dirent' used by the replacements is, of course, identical to what MinGW used up to now. So my suggestion would be twofold: . Have the implementation of 'glob', 'opendir', etc. reside in internal functions named, say, '__glob', '__opendir', etc., or some such, and call that internal name in the startup code. 'glob' will then call '__glob' as well. This should allow applications to have their own namesakes where they need them, without interfering with startup code. . Consider again the decision to break binary compatibility in dirent functions. I'm afraid this could cause numerous subtle bugs, e.g. when a library or DLL compiled with previous MinGW version is linked with a program compiled by the new MinGW headers. I understand the rationale for the changes (having glanced at the code) and the improvements they bring, but if I'm right in my assessment of the resulting incompatibilities, I'm afraid that the damage will be by far more serious than the benefits. (That's assuming that a solution cannot be found that keeps binary compatibility with previously compiled libraries; if such a solution exists, then it will allow us to have the best of both worlds.) TIA |