This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Define GNULIB_NAMESPACE in unittests/string_view-selftests.c
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Simon Marchi <simon dot marchi at ericsson dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 4 May 2018 09:55:52 -0700
- Subject: Re: [PATCH] Define GNULIB_NAMESPACE in unittests/string_view-selftests.c
- References: <1525382648-30186-1-git-send-email-simon.marchi@ericsson.com>
> When building with x86_64-w64-mingw32-g++ (to test cross-compiling for
> Windows), I get this error:
>
> unittests/string_view-selftests.o: In function `selftests::string_view::inserters_2::test05(unsigned long long)':
> /home/emaisin/src/binutils-gdb/gdb/unittests/basic_string_view/inserters/char/2.cc:60: undefined reference to `std::basic_ofstream<char, std::char_traits<char> >::rpl_close()'
>
> This is caused by gnulib redefining "close" as "rpl_close", and
> therefore messing up the declaration of basic_ofstream in the libstdc++
> header. The solution would be to use gnulib namespaces [1]. Until we
> use them across GDB, we can use them locally in files that are
> problematic, like this one.
>
> 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.
--
Joel