Re: [PATCH 2/3] Consistently use BFD's time

[Joel Brobecker <brobecker@adacore.com>]

> > Pedro> Can you clarify what do you see not work?  I tried rebasing it
> > Pedro> here, and it seems to work.  It builds cleanly on GNU/Linux and
> > Pedro> mingw32-w64 (both -m64 and -m32).  I've pasted the resulting patch below.
> > 
> > What if we apply this patch, but also apply a patch to our gnulib to
> > avoid the timezone offsetting?  We kept the code in
> > gnulib/update-gnulib.sh to make this pretty easy to do, and we could try
> > to work with upstream gnulib to make this feature optional (hopefully
> > eliminating the need for our patch).
> > 
> > This would avoid the mtime comparison problem.  I don't know how to
> > solve that another way, at least not without changing BFD to also use
> > gnulib -- which seems to come with its own risks.
> > 
> > Once we solve this somehow, I can rebase and update the original series
> > here.
> > 
> > This is one of the final blockers to the 10.1 branch, so it would be
> > good to reach some kind of resolution soon.
> > 
> 
> Hi,
> 
> [ it's been a bit more that two weeks since the last email on this, so
> I'm pinging this. ]
> 
> Joel wrote as summary here (
> https://sourceware.org/pipermail/gdb-patches/2020-August/171176.html ) :
> ...
> Hannes proposed, as a workaround, a hack involving
> undefining/redefining the fstat macro. The way it was proposed
> is not stricly portable as I understand it (it uses an extension),
> so we wouldn't be able to use it as is.  But I'm starting to
> warm to the idea of doing something like that on the branch,
> while we take the time we need to discuss the proper approach.
> ...
> 
> Is there any indication by now which way we want to go with this for the
> 10.1 branch?

For the short-term solution, I think the best compromise is to patch
gnulib like Tom suggests. We have the infrastructure to do that and
maintain the patch for as long as it takes to discuss the proper
solution (personally, I think the only way forward for the better
solution will require a live discussion; I am happy to help set that
up if people would find it useful).

Please let us know if you guys think there is a better short term
solution. Otherwise, let's ask Tom to submit a patch that patches
gnulib, and start creating the GDB 10 pre-release.

-- 
Joel