Re: executable wrapper on mingw mangles arguments

[Charles Wilson]

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