Ralf Wildenhues wrote: > I haven't finished the testsuite addition yet. This fix requires > such an addition.
Ack. > I think instead of Bruno's patch a much simpler fix is possible by > including a different header: > <http://thread.gmane.org/gmane.comp.gnu.mingw.user/27968/focus=28033> But that header is NOT part of the standard mingw runtime distribution. It is part of the execwrap add-on package: http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=59819 And, contrary to the statement in the referenced thread: "the only visible difference is that you include execwrap.h instead of process.h" you must also link against (and have available) libexecwrap.a. Now, currently libexecwrap is under the GPL; this is PROBABLY okay for us, because no-one should care if the wrapper executable is GPL; that won't "taint" the target program -- a separate "work" -- at all. IANAL, etc, etc. But to me, the real issue is availability: execwrap is NOT a default part of either the mingw or the msys distribution, nor is it present in any of the mingw-target toolchains distributed by the unix platforms. Now, IF Keith follows thru and adds the libexecwrap functionality to libmingwex, then at least "universal" availability could be assumed -- so long as _MINGW_RUNTIME_VERSION_ is high enough. We still have the concern that libtool would actually /break/ when used on a platform older than the one sporting this new functionality (unconditional include of execwrap.h) unless we did a LOT more #ifdef checking that we do at present, to determine when it's safe (or not) to include execwrap. (And what do we do when it is not safe? Silently include process.h and go with current buggy behavior?) Also, for execwrap to move into libmingwex, Keith has to be willing to un-GPL the code -- which he has resisted in the past. Furthermore, this mysterious co-author would have to agree... Even if it happened, all that would take time, and given the *GLACIAL* pace of mingw/msys development... > but I haven't checked yet whether that has license implications, > nor whether it actually works, nor whether it works for all system > and compiler combinations libtool cares about. > > If somebody could do all that, that would be great. For the reasons listed above, I'd lean more towards accepting Bruno's patch with all deliberate speed. -- Chuck