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

Pedro Alves
2019-03-12T10:52:53Z

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