`make`: mismatch in behavior launching `cmd`

[WardBrian]

I am trying to build a project that uses an older version of the Threaded Building Blocks library that uses cmd //C in a few places in their makefile.

This fails when using w64devkit, it appears to launch cmd and hang waiting for user input rather than running the command that follows. This behavior does not occur when using something like RTools or msys that provide similar environments for Windows.

It seems that cmd /C does work, but I believe that would break these other longstanding environments

---

As an aside, if I hack around these issues in TBB and try to proceed with the rest of my build, I get linker errors for standard library functions:

 undefined reference to `std::istream::seekg(std::fpos<_Mbstatet>)'

[WardBrian]

I guess it might be useful to state my overall goal: I'd love to be able to download cmdstan-2.38.0.tar.gz from https://github.com/stan-dev/cmdstan/releases/tag/v2.38.0, untar it, and sucessfully run make build.

[skeeto]

That's interesting, thanks for pointing this out. This is already handled in busybox-w32 as a special case for tools that assume an MSYS environment, mainly Autotools. However it's only for lowercase //c, because that's how Autotools spells it:

https://github.com/rmyorston/busybox-w32/blob/de7b34e8/shell/ash.c#L6954

It seems this ought to match //C as well. This is the first time I've seen a script use the uppercase version.

[skeeto]

I just realized that's not quite enough because it's only looking for echo, too. (Again, this is mainly an Autotools un-hack.)

The commands in that makefile strongly presume an MSYS environment. There is no virtual filesystem handling in w64devkit that will translate //nologo, etc. to /nologo.

[WardBrian]

Thanks for investigating. If supporting these kinds of older builds is out of scope I understand!

[avih]

Thanks for investigating. If supporting these kinds of older builds is out of scope I understand!

It's not about being out of scope.

This command is invalid. Try running in cmd.exe prompt:

cmd //C echo 123

and you will see that it starts a new cmd.exe prompt, doesn't do the echo, and doesn't exit it (i.e. now you're in a nested cmd.exe shell).

If you ran it in mingw gnu make from cmd.exe prompt - it will hang just like in w64dk.

This makefile was designed to run by MSYS2 make, and use MSYS2's bash to run sh commands in it, relying on its broken arguments translation.

The hack in busybox was meant to allow a very specific usecase of this form, specifically for autotools, which use it always in exactly one way: echo //c SOMEPATH.

Even this is uncalled for, because it will run something which cmd.exe itself doesn't run. But at least it tries to limit it to a very specific case.

Extending this hack further, effectively doing the same broken arguments translation which MSYS2's bash does - to cover these cases in a generic way, would ultimately break busybox-w32, because unlike MSYS2's bash, busybox-w32 users can rely on the fact that it doesn't mess with command arguments.

It's not impossible to translate args in busybox-w32 like MSYS2 does, but it's broken and we don't want to do that in busybox-w32.