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.