From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YAXxNbTK2F+rCQAAWB0awg (envelope-from ) for ; Tue, 15 Dec 2020 09:39:48 -0500 Received: by simark.ca (Postfix, from userid 112) id D950A1F0AA; Tue, 15 Dec 2020 09:39:48 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id DD9321E590 for ; Tue, 15 Dec 2020 09:39:47 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5B2CA386EC7C; Tue, 15 Dec 2020 14:39:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5B2CA386EC7C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1608043187; bh=JQHCl+aalN/0+JKDB2y5/yjNoUVmls/i+t16TqVbmAo=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Gvz5/sQr2a134JxkfOEXp5q4EN40PeWMzDEQYqBaqIP7d965heQaT65mRYBLDMYS1 6YnWrYmOO6uQhrJiXsYJYRVtgTf8C8wZWC9sZV7nqWipbfmp7Sx79MrWbT6DNtaOSQ iT2MfDqSQcwmtzs3W/rx0tUBUbgNDUwPk5RPVyEs= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 85B84386EC0E for ; Tue, 15 Dec 2020 14:39:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 85B84386EC0E Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 0BFEdIBH014915 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Dec 2020 09:39:23 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 0BFEdIBH014915 Received: from [10.0.0.213] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 552A21E590; Tue, 15 Dec 2020 09:39:18 -0500 (EST) Subject: Re: [PATCH v2] Enable GDB build with in-tree GMP and MPFR To: Joel Brobecker , Simon Marchi References: <20201118034455.GE617116@adacore.com> <71f5437f-c4f5-b58d-06f7-67a4d0b31007@simark.ca> <214e9564-5dfd-65a2-c2d8-6e8398ebc913@simark.ca> <87o8iw9ilx.fsf@tromey.com> <20201215023315.GK3461@adacore.com> Message-ID: <4ea7575a-b727-d9b7-e510-5c8b942f77f9@polymtl.ca> Date: Tue, 15 Dec 2020 09:39:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20201215023315.GK3461@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 15 Dec 2020 14:39:18 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: Pedro Alves , Bernd Edlinger , Tom Tromey , "gdb-patches@sourceware.org" Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2020-12-14 9:33 p.m., Joel Brobecker wrote: >>> Simon> It might mean that we have to stop using AC_LIB_HAVE_LINKFLAGS >>> Simon> though, or customize it. >>> >>> Yes. Perhaps alternatively we could promote its use to the top level. >>> It's maybe a pain to do that. >> >> Perhaps, but --with-{gmp,mpfr} would need to be kept as backwards >> compatibility. I think it would be hard to convince the gcc people of >> the benefits of such a change. > > Here's a radical question: Do we really need to stay in sync with GCC, > at this point? What are the benefits and requirements of doing so? > Because GCC doesn't coordinate with us when they make changes to > the toplevel configury, we're only going to get into these problems > more. Indeed, it's a bit annoying that the burden of syncing is only on one side. What are the original reasons for staying in sync with gcc? Instead of manually syncing files, I know Pedro already mentioned the idea of having a single repo with binutils + gcc + gdb, a bit like LLVM have moved to a big mono repo. Especially with gcc being a C++ program as well, we want to share more. So desyncing from gcc would make such a move more difficult. But it's just an idea at this point, so maybe it's not that important. Otherwise, just for convenience reasons, it would be nice to think more of gcc + binutils + gdb (an maybe others) as a single toolchain, and having consistency and no suprises in how you build them is a good thing for those build and integrate them. > In fact, how much does the toplevel configure really need to do? > Intuitively, it doesn't really need to do very much, if we ignore > all the stuff that's GCC-specific. I know next to nothing about the top-level configure, because I never needed to dig into it. > A more relevant conundrum, for me, might be to look at keeping > binutils and GDB in sync in terms of the options being used. > > And then we have the question of how to provide users who want to > configure parts or all of binutils-gdb what options they can use, > and what they do. I don't know how easy we can do that via the > toplevel configure's --help. One interesting question is: Would > doing so help us avoid inconsistencies with binutils? I'm not sure I understand. Do you mean, how do users get to learn about the configure switches of all projects? All I know is that you can do "./configure --help=recursive" from the top-level, but that's not particularly convenient, it just dumps all the helps from all the configure scripts. It's good if you want to find / grep. Simon