Subject: bug#49246: closed (Re: bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32))

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 15 Aug 2024 15:25:02 +0000

Your bug report

#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32

which was filed against the libtool package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
49246: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49246
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32)
From: Ileana Dumitrescu <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 15 Aug 2024 18:22:17 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi Brian,

On 14/08/2024 21:37, [email-masked] wrote:
> On 2024-08-14 12:10, Ileana Dumitrescu wrote:
>> Hi Brian,
>>
>> On 14/08/2024 20:40, Brian Inglis wrote:
>>> This is not a duplicate of that path bug.
>>>
>>> The `cmd //c ...` is not a path, which under Windows would contain 
>>> backslashes '\', it is an invocation of the Windows console command 
>>> line shell `cmd`.
>>>
>>> Those slashes are Windows console shell command line option switch 
>>> characters '/', with `cmd /c ...` meant to be equivalent to `sh -c ...`.
>>>
>>> It includes an invalid Windows options switch '//c', which results in 
>>> the Windows `cmd` shell being invoked as an interactive console 
>>> shell, as if invoked with the '/k' switch, but ignoring any provided 
>>> command string, hanging builds!
>>>
>>> For example, under Cygwin under Windows, I can reproduce this failure:
>>>
>>> $ cmd //c dir
>>> Microsoft Windows [Version 10.0.19045.4651]
>>> (c) Microsoft Corporation. All rights reserved.
>>>
>>> C:\...>exit
>>> $ cmd dir
>>> Microsoft Windows [Version 10.0.19045.4651]
>>> (c) Microsoft Corporation. All rights reserved.
>>>
>>> C:\...>exit
>>> $ cmd /c dir
>>>   Volume in drive C is SYSSW932GB
>>>   Volume Serial Number is EE45-4341
>>>
>>>   Directory of C:\usr\local\cygwin64\usr\src\cygport\ca
>>>
>>> 2024-08-14  09:55    <DIR>          .
>>> 2024-08-14  09:55    <DIR>          ..
>>> 2024-08-14  01:14    <DIR>          .git
>>> 2022-09-06  01:28    <DIR>          .github
>>> 2022-09-06  01:28                55 .gitignore
>>> 2022-09-06  01:28               103 .gitmodules
>>> 2022-09-06  01:28               478 AUTHORS
>>> 2024-05-07  01:50    <DIR>          bin
>>> 2024-08-14  01:13             1,137 COMMIT_MSG
>>> 2022-09-06  01:28            35,149 COPYING
>>> 2022-09-06  01:28            23,006 COPYING-DOCS
>>> 2024-08-14  01:10    <DIR>          cygclass
>>> 2024-05-07  01:50             7,981 cygport.spec
>>> 2024-05-07  01:50    <DIR>          data
>>> 2023-11-20  22:26    <DIR>          doc
>>> 2024-05-07  01:50    <DIR>          lib
>>> 2024-05-07  01:50               655 meson.build
>>> 2022-09-06  01:28                61 meson_options.txt
>>> 2024-05-07  01:50            41,198 NEWS
>>> 2024-05-07  01:50            10,295 README
>>> 2023-11-20  22:26    <DIR>          testsuite
>>> 2022-09-06  01:28               335 TODO
>>> 2022-09-06  01:28    <DIR>          tools
>>>                12 File(s)        120,453 bytes
>>>                11 Dir(s)  403,840,393,216 bytes free
>>> $ sh --c
>>> sh: 0: Illegal option --
>>> $ echo $SHELL
>>> /bin/bash
>>> $
>>>
>>> As shown above, if you invoke the equivalent `sh --c`, the shell 
>>> complains about the invalid option and exits, and does not hang 
>>> around as an interactive shell, but the Windows console command line 
>>> shell is more "helpful"!
>>>
>>> Even if you put that invalid Windows console command line inside a 
>>> Windows "batch" `cmd` script, it hangs the script at the interactive 
>>> console command line, until `exit` is typed interactively:
>>>
>>> $ head t.cmd
>>> cmd //c dir
>>> exit
>>> $ llgo t.cmd
>>> -rwxr-xr-x 1 12 Aug 14 11:21 t.cmd*
>>> $ cmd /c t.cmd
>>>
>>> C:\usr\local\cygwin64\usr\src\cygport\ca>cmd //c dir
>>> Microsoft Windows [Version 10.0.19045.4651]
>>> (c) Microsoft Corporation. All rights reserved.
>>>
>>> C:\usr\local\cygwin64\usr\src\cygport\ca>exit    <<<--- typed
>>>
>>> C:\usr\local\cygwin64\usr\src\cygport\ca>exit
>>> $
>>>
>>> I hope that better explains the issue, and am surprised that many 
>>> folks working on Windows (cross-) builds do not have a better handle 
>>> on the build environment, and its issues, as these communication 
>>> issues often recur.
>>>
>>> I characterize that personally as "Shit I shouldn't need to know!", 
>>> but I have had to, to do stuff like porting shell scripts to Windows 
>>> `cmd` scripts and utilities, for business continuity and disaster 
>>> recovery on user's home PCs. ;^>
>>>
>>> If you don't like running Windows, you can always run Cygwin under 
>>> Wine under Linux, as the two projects interoperate and cooperate, 
>>> also with Mingw64 and Msys2, so you can get wonderfully lost, as with 
>>> running under multi-level VMs.
>>>
>>
>> It seems I misunderstood the previous email that made it seem like this
>> was identified as a duplicate? I have reopened the bug, and I will look
>> into testing it.
> 
> Thank you very much, that would be greatly appreciated by our tool users.

I applied your patch through the existing testing framework and found no
issues, but I do not think I have the configuration setup to properly
test this bug. Looking through your explanation of the issue, I think
it is okay to apply the patch:

https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=37b7146c13a62a46273fd1478e6ad8fe42f9b551

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

Subject: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
From: Brian Inglis <[email-masked]>
To: [email-masked], Libtool Patches <[email-masked]>
Date: Sun, 27 Jun 2021 14:19:45 -0600
List-Id: <debbugs-submit.debbugs.gnu.org>

Problem reported by a downstream Cygwin user inadvertently
misconfiguring a package cross-build with mingw toolchain:

libtool with mingw hangs building openocd in
func_convert_core_msys_to_w32:

	https://cygwin.com/pipermail/cygwin/2021-June/248791.html

The issue exists in libtool build-aux/ltmain.in line 963 in
func_convert_core_msys_to_w32 Windows subshell command:

	( cmd //c echo "$1" )

see:

https://git.savannah.gnu.org/cgit/libtool.git/tree/build-aux/ltmain.in#n963

where the switch char "/" is duplicated, so instead of executing one
command in the Windows subshell context, a subshell is spawned and hangs
until manually exited e.g.:

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

C:\...>exit
$

The patch merely removes the extraneous duplicated switch char "/".

As the patch is trivial, no copyright assignemnt should be required.

---
 build-aux/ltmain.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96b3700347d5..4b8088903740 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -960,7 +960,7 @@ func_convert_core_msys_to_w32 ()
   $debug_cmd
 
   # awkward: cmd appends spaces to result
-  func_convert_core_msys_to_w32_result=`( cmd //c echo "$1" ) 2>/dev/null |
+  func_convert_core_msys_to_w32_result=`( cmd /c echo "$1" ) 2>/dev/null |
     $SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"`
 }
 #end: func_convert_core_msys_to_w32