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

[Joel Brobecker]

Hi Pedro,

> >> 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).
> > 
> > I discussed it live with Tom. We don't have the time to work on this
> > right now, so we'll send a patch in a week or so.  Given that everyone
> > has had a a lot of time to provide feedback on that thread, and given
> > the fact that we want to fix this before we branch, I don't think we
> > want to wait too long before getting that patch in -- assuming we are
> > still short on a better long term solution.
> > 
> 
> FWIW, I've tried to look at this more than once the past weeks,
> including today, hoping I'd find some nice solution, but all I got
> was a headache.

Yeah, cannot say I am surprised :-(, although I was thinking you might
be in posessions of some superpowers that made you able to find
a solution I couldn't. The fact that we have this hybrid situation
where GDB uses gnulib but one of its depedencies doesn't makes the use
of stat intractable, and if even you are having difficulties with it,
I think our only realistic options are to take a more radical approach,
either:

  - Stop using the stat module from gnulib (which I think we said
    we want to keep); or

  - Patch the gnulib implementation for now to block the incompatible
    behavior.

    The idea with this approach is that we'd try to work with gnulib
    maintainers to see if we could agree on a way to make the
    incompatibility conditional on something. That would be our way
    to eliminate this local change.

  - Something else?

-- 
Joel