Compilation of gettext-0.20.1 fails with "conflicting types for '_findclose'" error
On the face of it, this is a puzzling failure ... the error message shows identically the same declaration in both instances, so there really appears to be no conflict! However, re-running the failing command, with the -E option in place of -c, and the -o msgfmt-write-qt.o removed is rather more informative.
It may be noticed, even from the original error message, that <io.h> is included twice; initially by GnuLib's "iconv.h" wrapper, via <wchar.h>, and subsequently by GnuLib's "sys/stat.h" replacement. The first inclusion is selective, exposing only the subset of <io.h> content which Microsoft require to be exposed when including <wchar.h>, and thus, does not activate the _IO_H repeat-inclusion guard; the second is normal (full) inclusion, which does activate the _IO_H guard. The declaration of _findclose is exposed, supposedly identically in both passes, as does indeed appear to be the case, from inspection of the error message alone.
What isn't obvious, from the original error message, is that GnuLib introduces a conflict between the first and second inclusions of <io.h>. It may be seen, by inspection of the preprocessor output; during the first inclusion of <io.h>, _findclose is declared (correctly) thus:
However, by the time we get to the second inclusion, GnuLib has trashed the preprocessor environment, by the introduction of:
and thus, in the second pass through <io.h>, the declaration of _findclose becomes:
and GCC (correctly) rejects the change in the declared type of the function's argument.
Technically, this should be classified as a GnuLib defect ... it really should not subvert the system's <stdint.h> typedef of intptr_t, (as it does in statement #2 in the second code block of the preceding comment), in cases where the system implementation has provided one. (ISO C99, and later, leave it as optional for the system implementation to provide intptr_t, but when it is provided — as it is in mingwrt — then it becomes mandatory to also provide INTPTR_MIN and INTPTR_MAX macro definitions, so GnuLib could — and should — readily check availability).
Notwithstanding that this issue arises from a GnuLib bug, its effect may be mitigated by the attached patch.
I pushed the proposed patch to the code repository.
Mitigation is incorporated within mingwrt-5.3.
When compiling GNU gettext-0.20.1 with GCC-8.2.0 and mingwrt-5.2.2, I see: