From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69202 invoked by alias); 12 Mar 2019 10:52:53 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 69191 invoked by uid 89); 12 Mar 2019 10:52:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=feet, Friday, friday, invasive X-HELO: mail-wm1-f67.google.com Received: from mail-wm1-f67.google.com (HELO mail-wm1-f67.google.com) (209.85.128.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Mar 2019 10:52:51 +0000 Received: by mail-wm1-f67.google.com with SMTP id e16so1970091wme.1 for ; Tue, 12 Mar 2019 03:52:51 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id l130sm1798133wmf.13.2019.03.12.03.52.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Mar 2019 03:52:48 -0700 (PDT) Subject: Re: MinGW build failure for GDB 8.2.90 with source-highlight To: Simon Marchi , Eli Zaretskii References: <83r2bibvlv.fsf@gnu.org> <83ef7d5wak.fsf@gnu.org> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <3f85112b-0b3f-fb74-e61e-88e12164b740@redhat.com> Date: Tue, 12 Mar 2019 10:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2019-03/txt/msg00235.txt.bz2 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 >>> ? >> >> 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