> The only thing that is guaranteed to work is to always create the children processes with a NULL environment ...
This has been stated twice as an absolute fact but it leaves an obvious question: why can't GNU make dig up these special "=" env vars on its own and add them to its custom "envp" environment? On Mon, Nov 29, 2021 at 5:38 AM Liviu Ionescu <invalid.nore...@gnu.org> wrote: > Follow-up Comment #8, bug #61409 (project make): > > > Your suggestion to modify the Make's own environment also won't work > well, > because Make invokes programs asynchronously, i.e. it doesn't wait for the > child to exit, and so modifying Make's environment will affect Make itself > > I'm not sure this is accurate, my understanding is that the environment is > copied to the child, so once the child is created, the parent can further > change its own environment unhindered. > > > report this bug to Microsoft > > I'm currently investigating on how to report this to Microsoft, but, as I > said, even if Microsoft fixes the bug, millions of older installs will > fail. > > > and to MinGW64 folks, and hope that they fix it in a future release. > > The folks at Mingw-w64 helped with the detailed diagnose. There is not much > they can do. The only thing that is guaranteed to work is to always create > the > children processes with a NULL environment, and this is up to the > application. > > Remember, the BusyBox sh.exe, which was the first UCRT program to fail when > invoked by make.exe, so the same sh.exe binary works just fine when invoked > from cmd.exe. I'd bet that cmd.exe creates the process with a NULL > environment. > > So, when I report this to Microsoft, they might very well reply that > cmd.exe > works, and if make.exe doesn't, I should report this to GNU make folks. ;-) > > > > > _______________________________________________________ > > Reply to this item at: > > <https://savannah.gnu.org/bugs/?61409> > > _______________________________________________ > Message sent via Savannah > https://savannah.gnu.org/ > > >
