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 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 49246 <at> debbugs.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)]
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
[Message part 3 (message/rfc822, inline)]
[Message part 4 (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)]
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.