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

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.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry


On 2024-08-14 09:58, GNU bug Tracking System wrote:
> 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 [email protected].
> 
> -- 49246: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49246 GNU Bug Tracking 
> System Contact [email protected] with problems
> 
> 
> ForwardedMessage.eml
> 
> Subject:
> Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
> From:
> Ileana Dumitrescu <[email protected]>
> Date:
> 2024-08-14, 09:56
> 
> To:
> [email protected]
> 
> 
> This looks like a duplicate of bug#10949:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949
> 
> It explains why the double slash is intentional and where in the
> documentation to look to better understand cross-building.
> 
> -- 
> Ileana Dumitrescu
> 
> GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
> 
> ForwardedMessage.eml
> 
> Subject:
> [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
> From:
> Brian Inglis <[email protected]>
> Date:
> 2021-06-27, 14:19
> 
> To:
> [email protected], Libtool Patches <[email protected]>
> BCC:
> Brian Inglis <[email protected]>
> 
> 
> 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
> 
> 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