> > gdb/ChangeLog:
> > 
> > 	* unittests/string_view-selftests.c: Define GNULIB_NAMESPACE.
> 
> I noticed the exact same problem, and came up with the exact same
> solution. Sorry for not reporting right away, I have been swamped
> :-( and also wanted to spend some more time investigating the bigger
> picture; it seems to me like we may be having a huge time bomb
> in our hands?!?
> 
> In other words, either we don't define GNULIB_NAMESPACE, but then
> we run into unwanted renames of class method names; or we defined
> GNULIB_NAMESPACE, but that means we must be prefixing all the symbols
> we call that are covered by the imported part of GNULIB with that
> namespace.
> 
> What worries me is that I don't see what's preventing us from hitting
> that issue outside of the unittests code? We know we can adjust our
> own classes, but this problem occured with a system class, so we had
> no choice but to use GNULIB_NAMESPACE. I worry that the transition
> from no GNULIB_NAMESPACE to using GNULIB_NAMESPACE in a given unit
> will leave some C system calls that should normally be covered by
> gnulib silently now reverting to the system (buggy) version.

Actually, for the record, here is the patch I came up with.
Similar in nature, but additional comments and also only defining
the GNULIB_NAMESPACE macro on Windows hosts -- as a strategy to
minimize impact.

I think your approach is best, as we'll at least get the same
conditions regardless of the host.

-- 
Joel