Hi Olivier, > -----Original Message----- > From: Olivier Hainque [mailto:hain...@adacore.com] > Sent: Tuesday, November 28, 2017 10:40 > To: Tamar Christina <tamar.christ...@arm.com> > Cc: Olivier Hainque <hain...@adacore.com>; David Malcolm > <dmalc...@redhat.com>; Jeff Law <l...@redhat.com>; GCC Patches <gcc- > patc...@gcc.gnu.org>; nd <n...@arm.com> > Subject: Re: [PATCH, Makefile.in] refine selftest recipes to restore mingw > bootstrap > > Hello Tamar, > > > On Nov 28, 2017, at 11:05 , Tamar Christina <tamar.christ...@arm.com> > wrote: > > > > Yeah I choose this fix because /dev/null is converted to "nul" by the > > Cygwin/msys2 runtime. So when invoked On the shell it gets converted > > before GCC sees it. > > > > Nothing against using nul directly, though I am surprised that there's > > an environment that provides Configure, automake and coreutils which > > doesn't convert /dev/null to nul. > > My understanding is that it's not only a property of the environment in which > the tool gets executed, but also of the tool itself. > > For gcc in particular, ISTM it depends on the target for which you configured.
This is true, but In this case, the tool should have never seen "/dev/null". Since the invocation Of the command that uses SELFTEST_FLAGS should have converted it. Unless you're using Something like mingw32-make, which would explain the difference. > > Our toolchains are configured for x86_64-pc-mingw32 > > Maybe yours are configured for cygwin, not mingw (are they ?), and then are > linked with cygwin libraries which perform various transformations. No, mine are configured for x86_64-w64-mingw32 and are just native gcc builds. It's just build using cygwin derived tools to not encounter certain differences like this one. I think using nul is fine if it makes your use-case work, it shouldn't break the mingw64 builds. Thanks, Tamar > > Olivier >
