Re: Problem building today's snapshot with MinGW

[Joel Brobecker <brobecker@adacore.com>]

> At Joel's request, I've built today's snapshot of the GDB master
> branch using mingw.org's MinGW, and found a problem when running the
> produced gdb.exe on versions of Windows older than 8.0 (in my case it
> was XP).  The details are described in my report to the Gnulib folks:
> 
>   https://lists.gnu.org/archive/html/bug-gnulib/2020-09/index.html

FTR, the direct link to the actual email is:
https://lists.gnu.org/archive/html/bug-gnulib/2020-09/msg00027.html

> The provisional patch I used to solve this problem is this:

I created the following gdb/build PR:

    https://sourceware.org/bugzilla/show_bug.cgi?id=26607

> --- gnulib/import/stat-w32.c~	2020-09-10 04:47:11.000000000 +0300
> +++ gnulib/import/stat-w32.c	2020-09-10 16:05:46.789125000 +0300
> @@ -20,10 +20,14 @@
>  
>  #if defined _WIN32 && ! defined __CYGWIN__
>  
> +#if _GL_WINDOWS_STAT_INODES == 2
>  /* Ensure that <windows.h> defines FILE_ID_INFO.  */
> -#if !defined _WIN32_WINNT || (_WIN32_WINNT < _WIN32_WINNT_WIN8)
> -# undef _WIN32_WINNT
> -# define _WIN32_WINNT _WIN32_WINNT_WIN8
> +# if !defined _WIN32_WINNT || (_WIN32_WINNT < _WIN32_WINNT_WIN8)
> +#  undef _WIN32_WINNT
> +#  define _WIN32_WINNT _WIN32_WINNT_WIN8
> +# endif
> +#elif !defined VOLUME_NAME_NONE
> +# define VOLUME_NAME_NONE 0x4
>  #endif

From what I understood of the analysis, gnulib is doing something
pretty questionable (forcing _WIN32_WINNT to the wrong value) in
order to get FILE_ID_INFO being defined; and looking at your patch
and the explanation you gave in the report to gnulib, you found
that the APIs in question are only needed if _GL_WINDOWS_STAT_INODES
and so fixed this by only enabling the redefined based on
this variable. So for me, this is more of a workaround than an actual
fix. Between this and the fact that all versions of Windows older
than 8.1 are no longer supported by Microsoft, I can anticipate
some push back from the gnulib community.

The question we then want to ask ourselves, is whether we want to
continue supporting older versions of Windows. I'm personally not
opposed, but it has to be at a reasonable cost, meaning that it can
only be acceptable if changes made to support those versions don't
increase the maintenance burden. Unfortunately, I don't think
the patch above meets those requirements.

I'm not opposed to having some kind of fix to be discussed in
the upcoming gdb-10-branch, though, because there we know the extra
burden would only last as long as the branch itself.

Thoughts?

-- 
Joel