[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

[Mitch]

Follow-up Comment #3, sr #110901 (project libtool):

OK! Sorry for not investigating further, once I found the mailing list thread
that seemed like it terminated with the proper fix (and verifying it fixed it
for me) I stopped debugging the issue.

It is now clear.  I think this relates to the MSYS2 variable
MSYS2_ARG_CONV_EXCL  which controls what is or is not escaped.  By default
msys tries escaping any and all command line args with slashes thus leading do
the cmd //c fix in use.

Of course once you start trying to do a large variety of program calls MSYS2
escaping causes more errors than fixes.  MSYS2 resolves this by using
MSYS2_ARG_CONV_EXCL to specify what patterns should not be escaped, but if you
are like me (and I am guessing the person who originally posted to the ML) you
might just do MSYS2_ARG_CONV_EXCL="*"  to turn of escaping all together.  Now
there is the problem that libtool has those built in hacks to get around the
msys2 limitations but msys2 won't be escaping it leading to the literal //c
being passed to cmd.exe causing this hang.

The best solution here may be for libtool to unset MSYS2_ARG_CONV_EXCL prior 
to executing a cmd shell thus guaranteeing the brute escaping it expects.

Personally I think getting to the other position (forcing all escaping off) is
a better long term solution as you don't have to worry about any potential
funky modification when making native calls.   MSYS2 and native Windows do
share a path format that works for both in nearly all situations and that is:
c:/test/my/file.txt   virtually all msys2 and windows executables accept that
without issue and there are no backslashes to worry about fixing.  It has the
side effect that msys also won't try to do any path conversion on the way out.
  There are a few limitations to this:
*) You need to make sure your paths are in that format, if you don't know if
something is a path or not that may not be doable
*) If you are trying to pass a msys2 filesystem file to a native command the
prefixing has to be done manually (ie something that is in the msys2 root like
/etc/myconfig.conf needs translating to c:/msys64/etc/myconfig.conf ).


That may be a pipe dream not worth considering, and the first solution of
setting the ENV var before the call may be the best way to go.

I will say I have been compiling a massive amount of foss software
(https://github.com/mitchcapper/WIN64LinuxBuild) as close to native windows as
possible from inside msys2 and despite having the escape fixes turned off this
is the first time I have run into this problem.  Prior to disabling the
automatic conversion though there were a good bit of issues.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?110901>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/