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

Hi Brian,

On 14/08/2024 21:37, [email protected] 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