"It is standard practice when updating gnulib to discuss the set of
modules that the exercise brings in due to module dependencies.
If we're now including some more modules, that may mean that
we could eliminate some older host compatibility code from gdb
in favor of gnulib's and list the module dependencies
explicitly in IMPORTED_GNULIB_MODULES in update-gnulib.h.
Conversely, there's a chance that we were depending on some
module that wasn't explicitly listed in IMPORTED_GNULIB_MODULES,
and an update could remove the module by mistake.
Another reason for that is that that are some modules that
are problematic for us (e.g., the one that pulls in Windows's
select replacement), so we need to look out for that, in case
it is pulled in by a dependency."
It seems what is getting removed is:
- dosname (deprecated module and we don't use dosname.h)
- gettimeofday (it looks like we use this in remote-fileio.c)
- localtime-buffer (looks like basically an implementation detail)
- sys_time (looks like GDB specifically did *not* want this per
comments in gdbsupport/gdb_sys_time.h)
> On 7/2/20 8:02 PM, Eli Zaretskii wrote:
> >> From: Pedro Alves <[hidden email]>
> >> Date: Thu, 2 Jul 2020 19:49:53 +0100
> >>> This fixes two issues on Windows: Update.
> >>> https://sourceware.org/pipermail/gdb-patches/2020-June/169978.html > >>
> >> This seems to be bringing in a good amount of churn.
> > Maybe we should just update the two modules which were changed due to
> > my reports? Would that be safer?
> I don't know. I'd be happy with just seeing the list of the
> dependencies being pulled in and dropped before making such
> a decision. It's just a precautionary measure, the update is
> probably fine.
> Pedro Alves