GNU bug report logs -
#49246
[PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Thu, 15 Aug 2024 18:22:17 +0300
with message-id <98ede77f-9d86-43fc-8128-323758b719f1 <at> gmail.com>
and subject line Re: bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32)
has caused the debbugs.gnu.org bug report #49246,
regarding [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
49246: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49246
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
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(-)
[0001-libtool-with-mingw-hangs-in-func_convert_core_msys_to_w32.patch (text/x-patch, attachment)]
[Message part 5 (message/rfc822, inline)]
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.