Re: MinGW build failure for GDB 8.2.90 with source-highlight

[Pedro Alves <palves@redhat.com>]

On 03/12/2019 02:31 AM, Simon Marchi wrote:
> On 2019-03-11 10:18, Eli Zaretskii wrote:
>> Ping!  This discussion seems to have stalled.  I'd like to have it
>> solved before GDB 8.3 is released.
> 
> Agreed, this is definitely a blocker for the release.  I recorded it here:
> 
> https://www.sourceware.org/gdb/wiki/GDB_8.3_Release
> 
>> If no better ideas come up, I'd like to commit the change described
>> here:
>>
>>> Perhaps we should simply #undef these two symbols before including
>>> <fstream>?
>>
>> TIA
> 
> If the change is localized in one or a handful of files, I think it would be acceptable for the 8.3 release, since the alternative solution would be (1) a lot of work and (2) risky.
> 
> Can you post a patch that fixes the build for you?
> 
> Pedro, did you have a branch where you put all of gdb in the gdb namespace?  I only found this branch, but it's using the gnulib:: namespace, which is not the same.
> 
> https://github.com/palves/gdb/commits/palves/cxx-gnulib-namespace
> 

Right, not that one.  That was the first attempt, and then I almost posted
that one upstream at the time.  I was about to press 'git send-email' but
got cold feet, thinking there must be a better way.  That's when
I tried the "namespace gdb" approach instead.  And that one is in
the branch I pointed at in my previous message:

> Prototyped here:
>  https://github.com/palves/gdb/commits/palves/cxx-gdb-namespace

Note: cxx-gdb-namespace != cxx-gnulib-namespace

> I just started to try to do it to get a feel of what's needed.  I guess we need to put pretty much everything except includes (and maybe some other rare exceptions) between namespace gdb { ... }?  And of course define GNULIB_NAMESPACE to gdb.
Yes, that's the gist of it.  

I've actually been working on that since Friday.  Spent a chunk of the weekend
on it, and some time yesterday.  Meant to reply back yesterday, but something
got in the way.

I have a script in the branch that does a good chunk of the work, but unfortunately,
it still requires a lot of manual touching up.  I thought the rebase would be
trivial, but with all the new files and churn in the codebase since 2016, it
still involved a lot of manual re-work.  I have it building on x86-64 now.
I've forced pushed what I have now.  The branch has >130 patches currently, most of
the them are small per-file patches.  I need to clean this up a bit, squash some
of the fixes-on-fixes patches.  I'm not exactly sure how to post this to the
list...  And also, of course this needs at least build-testing on a wider set
of hosts/cross compilers.  Maybe people could take a preliminary look at the
branch, see if they agree with direction?

But in any case, I think this would be too invasive for the 8.3
branch.  A smaller fix there would be safer.

Thanks,
Pedro Alves