[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:

  

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

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

[Evgeny Grin]

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

[(Ошибка - не найдено)]
When starting any program under MSYS (and MSYS2), the MSYS[2] checks whether
the lunched program is linked with msys-*.dll. 
If program is linked with this DLL then the program expects POSIX-like
environment so no path translation is performed.
If program is not linked with this DLL then the program is native Windows
binary, which expects native Windows paths. In such case the MSYS[2] scans all
arguments for POSIX-like paths and converts all of them to Windows native
paths. The problem is that all Windows drives are mounted as single letter in
the root so the path like "/d/path/file" should be translated into
"D:/path/file", while "/c" is translated into "C:/"
To prevent this translation double slash could be used. Double slash is
replaced with single slash.

Examples:


MSYS ~
$ cmd /c echo "/c"
Microsoft Windows [Version 10.0.19045.3208]
(c) Microsoft Corporation. All rights reserved.

C:\msys64\home\user>exit

MSYS ~
$ cmd //c echo "/c"
C:/

MSYS ~
$ cmd //c echo "//c"
/c

MSYS ~
$ cmd //c echo "///c"
//c

MSYS ~
$ echo.exe "/c"
/c

MSYS ~
$ echo.exe "//c"
//c

"echo.exe" is Msys program. cmd is not Msys program.


___

Reply to this item at:

  

___
Сообщение отправлено по Savannah
https://savannah.gnu.org/

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

[Evgeny Grin]

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

[(Ошибка - не найдено)]
No, it's wrong.
See https://sourceware.org/pipermail/cygwin/2021-June/248814.html


___

Reply to this item at:

  

___
Сообщение отправлено по Savannah
https://savannah.gnu.org/

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

[Mitch]

URL:
  

 Summary: libtool hangs indefinitely on windows when used in
msys due to cmd.exe call bug
   Group: GNU Libtool
   Submitter: mitchc
   Submitted: Wed 19 Jul 2023 07:23:17 AM UTC
Category: None
Priority: 5 - Normal
Severity: 4 - Important
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Microsoft Windows


___

Follow-up Comments:


---
Date: Wed 19 Jul 2023 07:23:17 AM UTC By: Mitch 
Seems the bug was reported with fix a few years ago but sadly did not get
applied:

https://lists.nongnu.org/archive/html/libtool/2021-06/msg1.html







___

Reply to this item at:

  

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