Hi Eli, > The problem described below was found when building the latest pretest > of wget2 with mingw.org's MinGW system headers and libraries.
Oh, there are still people who use the (old) mingw.org system? I thought everyone by now had switched to mingw-w64. This (newer) mingw does not exhibit the behaviour you describe: <time.h> https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/crt/time.h <sys/types.h> https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/crt/sys/types.h Hmm. mingw.org points me to this source: <time.h> https://sourceforge.net/p/mingw/mingw-org-wsl/ci/21762bb4a1bd0c88c38eead03f59e8d994349e83/tree/include/time.h which also does not fit your description: it doesn't include <sys/types.h>. > This assumes that the system header sys/types.h can be included just > once, anywhere in the program, and that is sufficient. (MinGW's > time.h includes sys/types.h, which causes it to include Gnulib's > sys/types.h.) Is that a portable assumption? In general, it is a portable assumption. There are very few cases where such an assumption does not hold, and it requires special handling with special #ifs in gnulib. > What happens with MinGW headers is that when MinGW's sys/types.h is > included from time.h, only a small portion of sys/types.h is > processed, the one that is relevant to time.h types, and that portion > doesn't include the types mentioned in the above error messages. The > next time sys/types.h is included by the program, the Gnulib header > decides it doesn't need to delegate to the system header, because > _@GUARD_PREFIX@_SYS_TYPES_H is already defined. So the relevant > portions of MinGW's sys/types.h are skipped, and we get the error > messages. Please can you attach - a copy of the mingw <time.h>, - a copy of the mingw <sys/types.h>, - the result of preprocessing utimens.c with "-E"? Thanks. Bruno
