MinGW build failure for GDB 8.2.90 with source-highlight

[Simon Marchi]

On 2019-03-07 13:20, Pedro Alves wrote:
> On 03/07/2019 06:09 PM, Simon Marchi wrote:
>> On 2019-03-07 12:11, Pedro Alves wrote:
>>> On 03/07/2019 04:59 PM, Simon Marchi wrote:
>>> 
>>>> I don't recall what's the long term solution for this.  We could use 
>>>> gnulib's namespace support [2], but the disadvantage is that we 
>>>> would need to use gnulib::some_function (assuming we name the 
>>>> namespace "gnulib") instead of just some_function to use the "fixed" 
>>>> version.  If we use some_function directly, it will use the buggy 
>>>> version on those systems where it is buggy.
>>> 
>>> Wrap all of gdb in a namespace.  Recall that this was what led to C++
>>> wildmatching support.
>> 
>> I don't understand how this will help.
> 
> Sorry, I thought the reference would make you recall
> the previous discussions.  See below.

Yeah, I recalled these discussions, but I couldn't make the pieces fit 
in my head...

>> If you have
>> 
>> #define open rpl_open
>> 
>> namespace gdb {
>> Â  struct target_ops {
>> Â Â Â  void open();
>> Â  }
>> }
>> 
>> The macro will still wrongfully replace open.
> 
> See slides #16-#17 of my Cauldron 2017 presentation:
> 
> 
> https://gcc.gnu.org/wiki/cauldron2017?action=AttachFile&do=view&target=gdb+-+C%2B%2B+conversion+%26+dogfood.pdf
> 
> The idea is to put all of gdb under "namespace gdb", and also put
> gnulib in the same namespace, using gnulib's namespace support.
> That way, there are no macros, and, the code looks just like it
> does today, except for the "namespace gdb" wrapping.
> 
> Prototyped here:
>  https://github.com/palves/gdb/commits/palves/cxx-gdb-namespace

Ok, the key I was missing is that gdb and gnulib are in the same 
namespace, so if you call "close", for example, it uses gnulib's close.

Thanks!

Simon