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.
OpenPGP_0x6570EA01146F7354.asc