> Cc: groff@gnu.org > From: Keith Marshall <keith.d.marsh...@ntlworld.com> > Date: Wed, 13 Feb 2019 03:01:38 +0000 > > > You seem to be saying that we *cannot* require C99/POSIX conformance > > from toolchains on target systems without critical breakage. > > That's exactly what I'm saying. POSIX requires fork(2); Windows doesn't > support it. Where groff sets up a pipeline, using fork(2) and exec(3), > with I/O hook-up performed between, Windows *must* perform the I/O > hook-up in the parent, then call spawn(), (or the significantly uglier > CreateProcess()), to invoke the child, and then revert the effect of the > I/O hook-up in the parent. There is no other way of getting around this > Windows limitation; that's the purpose of the bulk of groff's > Windows-specific code, and the spawn() API has remained substantially > unchanged, in over 20 years.
Just to make what Keith says (and I concur) crystal clear: there's a need to distinguish between C99 compliance of the compiler and the C99/Posix compliance of the C runtime. We can assume the former, certainly when using MinGW GCC, but we cannot assume the latter when building a native MS-Windows port (as opposed to Cygwin port) of Groff. I doubt that Griff nowadays includes support for MSVC, the Microsoft compiler, I think that all those #ifdef _WIN32 parts are for any native MS-Windows build, including MinGW: they are there because MSVCRT.DLL, the Windows C runtime library, lacks many Posix functions. > > How does the build recipe work under Winows? Does it run shell and m4? > > How it works with MSVC, or with DJGPP, I don't know. DJGPP has working ports of Bash, m4, and Perl, so it runs the GNU configury like Posix hosts. > For MinGW, it uses the conventional GNU build model, (in MinGW's > MSYS environment). Right.
