>> 1. frexp.c is not needed, as Visual Studio already provides frexp() function via system libraries.
>But probably with bugs. And even if it is not needed on your platform,
>it is part of the tarball to replace broken frexp() on systems where it
>is buggy. Part of configure determines if it is needed on your platform.
Possibly, but why is the chance on bugs on Microsoft's frexp() higher? The only (unfortunately common) practice of Microsoft is that they may differ from 'standard' behavior on Linux.
>I'm less certain on the solutions for the others, although patches to
>gnulib are welcome.
I'm not sure whether I've the knowledge to do so, but today I tried to get gdiff also compilable in Cygwin shell (with all required environment variables used by Visual Studio's cl.exe properly set) + CC=cl.exe ./configure
And funny enough, I'm recognizing things. Gdiff also uses gnulib. A piece of the output is:
checking absolute name of <wchar.h>... ""
So if a system header is not found, it expands to an empty string. Because Microsoft Visual Studio does not recognize the include_next pragma, I used the following trick:
The #include[_next] "" directive was replaced by #include "../ucrt/headerfile". This works well for the Windows 10 SDK. If an older Visual Studion version is used, use #include "../include/headerfile", where <headerfile> can be replaced by any system header
(e.g. wchar.h or sys/types.h).
What is the recommended to get this behavior changed? It requires changes in configure to detect whether a ‘dotdot’ construct works for visual studio (and only of compiler matches with cl[.exe]) and if the header indeed exists (Windows has e.g. no dirent.h
and much other UNIX style headers).