[PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

Pedro Alves palves@redhat.com
Thu Aug 4 22:37:00 GMT 2016

On 07/31/2016 11:50 PM, Manuel López-Ibáñez wrote:

> Oh well, Ayush does not have access to different hosts, thus I
> guess it is better that he focuses his limited time on functions that
> he can test. There are plenty of functions that are both in gnulib and
> libiberty but not in glibc.

My experience on the gdb side is that these kinds of patches tend
to move much faster if there's confidence they got wide host testing.  

I'm not a gcc maintainer, but I'd suggest:

 - Put the patches on a public branch (e.g., a personal branch in
   the gcc git mirror), and point at the branch in patch
   submissions.  A branch is easier for the occasional passerby testing
   than downloading a patch and then curse a bit while trying to
   to figure out the base revision the patch was generated against, because
   it no longer applies cleanly on current trunk.

 - Explicitly call for testing help, pointing at the branch.  This makes
   it possible for a global maintainer to reasonable call a timeout.
   As in, "as we've called for testing X ago, and clearly nobody cares,
   let's go ahead, and fix any fall out afterwards.")

 - Get access to the gcc compile farm and go the extra mile of testing
   the patches on a couple non-GNU/Linux hosts.  For example, there are
   AIX and NetBSD boxes there.  I sometimes do this on the gdb side,
   and it helps much with moving things along.

 - Still on the extra mile theme, install cross compilers, and
   cross build gcc for those.  For example, Fedora has a mingw-w64
   toolchain in the main repo, which makes it's easy to at least
   cross build for Windows.

Pedro Alves

More information about the Gcc-patches mailing list