Re: Build failure following: Implement support for checking /proc/PID/coredump_filter commit

[Pedro Alves <palves at redhat dot com>]

On 04/08/2015 05:27 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> There's also the "users/palves/gnulib-update" branch that
>> updates gdb's copy of gnulib to recent gnulib master.  It'd
>> be great if someone confirmed that a gdb build of that branch
>> actually works on Windows, so we can move forward with that.
>> (the branch predates Sergio's patch, so isn't affected by the strtok_r
>> issue).  I'd be nice to update our gnulib copy before we pull in
>> more modules, to avoid tripping on bugs that have meanwhile already
>> been fixed upstream, or avoid module dependencies that may
>> have been reduced upstream...
> 
> On the other hand, updating our gnulib copy from upstream may introduce
> new bugs.

Sure.  And we can report and fix them, or downgrade a few revisions to
before when the bug was introduced.

> strtok_r exists in the gnulib
> 8d5bd1402003bd0153984b138735adf537d960b0 commit we are using, I don't

That's actually what I did in the branch I pointed Pierre at.

> see why we need to update our gnulib copy, unless there are some known
> bug fixes in gnulib upstream.

Why risk stumbling on bugs that might have been fixed in the 3
years since the last import?  The more modules we import off the older
copy, the wider the potential-bugs surface.  And then what to do if we
need to patch gnulib?  If the requirement is to send the fix upstream
first, and then refresh our import, it'll be much easier if the
re-import is just a small incremental update, rather than pulling in
multiple years of gnulib work.  The further apart our update is, the
harder it is to update.  If we keep our copy reasonably up to date, we
have a better chance of whoever introduced the bug upstream to still have
the issue fresh in mind and provide a prompt fix.  If we wait 3 years
to report a bug, then the chances are good that we get to fix
it ourselves.

I currently want to update gnulib for at least 3 reasons:

 - GDB-in-C++ on mingw:

   https://sourceware.org/ml/gdb-patches/2015-03/msg00447.html

   That will have to be fixed on gnulib.  Haven't checked if
   already fixed there, but most probably it is.

 - Antoine's use of canonicalize:

   https://sourceware.org/ml/gdb-patches/2015-03/msg00917.html

   That pulls in a truck load of modules.  I'd hope the dependencies
   are fewer in a newer gnulib, or at least, if the dependencies are the
   same, I'd much prefer importing up-to-date versions.  Otherwise, the
   poor soul that next updates gnulib is likely to have a "fun" time.

 - Pull in the fts module to get rid of the "system" call in compile/,
   as discussed a while ago.

I think now's the best time, as we still have time till the next
gdb release.

Thanks,
Pedro Alves