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.