GNU bug report logs -
#49246
[PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
Previous Next
Full log
Message #29 received at 49246-done <at> debbugs.gnu.org (full text, mbox):
Hi Brian,
On 14/08/2024 21:37, Brian.Inglis <at> SystematicSW.ab.ca 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
This bug report was last modified 277 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.