mainGNU Libtool - Support: sr #110901, libtool hangs indefinitely on...


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

Submitter:  Mitch <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
Open/Closed:  Open Operating System:  Microsoft Windows
* Mandatory Fields

Add a New Comment Rich Markup

Fri 28 Jul 2023 10:59:38 PM UTC, comment #3: 

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 ( 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.

Mitch <mitchc>
Tue 25 Jul 2023 04:21:14 PM UTC, comment #2: 

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.


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


$ cmd //c echo "/c"

$ cmd //c echo "//c"

$ cmd //c echo "///c"

$ echo.exe "/c"

$ echo.exe "//c"
"echo.exe" is Msys program. cmd is not Msys program.

Evgeny Grin <karlson2k>
Tue 25 Jul 2023 04:05:07 PM UTC, comment #1: 
Evgeny Grin <karlson2k>
Wed 19 Jul 2023 07:23:17 AM UTC, original submission:  

Seems the bug was reported with fix a few years ago but sadly did not get applied:

Mitch <mitchc>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by karlson2k (Posted a comment)
  • -email is unavailable- added by mitchc (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code