From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-oln040092075050.outbound.protection.outlook.com [40.92.75.50]) by sourceware.org (Postfix) with ESMTPS id 73B5E3844046 for ; Tue, 15 Dec 2020 16:24:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 73B5E3844046 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hotmail.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bernd.edlinger@hotmail.de ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hJrkaxlXnsjx/UgbH3RC9rFUPhxEINz+Ymy3NdtuIcHih4zqTANA2OUr5SSA+U4WPPRA8LUa60yFOv2FJi+29PK5cegmA0uWS0Vm6tKLL17Qf/cjm6+UIE3rF6pC5qLYhEj5+YUlZ9w9mlkFXw4GgCTXYcQyv4BDB492ugnoXbuu+ZYykUl5IODlNZzj2JkMLXeTpN+uu0AEXgEeGYTQq4UHBByzoc34e/+I94qbcUwOg/FBFH9XZP6xnPm1NpMpjHZ96pRV2SwadDYy+BQ8Lk708mUTJd6cC3nybCyuKwHbFruvu2O4Badis3phMX9WA8Ath9PyokzmHELygzHLNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DpiWEqF6eEjLdknz4BCDfFDgrlAFIgsP3R7HZVMrkM0=; b=PeBUOmiBJ+FxnWsf2p6CH6uanazEfoX+EWx2AMIhRUkhkGDZBhm0v6+tbn3CfDXzBXu6ayp3jjHgXrQLDcMCuFVtfYKvkPhlhES9Hze3MYeJ1WUqmRQwMQYm/8acm5QhXhH7Q7RRt1n2L8VimrXMfyKjFOFvQE+k8x0bBJiSlk1hrkFGGG5ls54V6lT9Yob+1vo3xmX4P4hHF4gBvnMfDYt4qKA6M1R17gQaRpGN31puB8+gWeyRI8EviAGE5c00J6F6gBFktGl22G8ZSpWXr3qFgOfBfCoAgd0B0+wiGq4nY4OQwOYQCi19ansbXXOHXYZpiy6O9jdn6JlEhfGXew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DB3EUR04FT033.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0c::4d) by DB3EUR04HT127.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0c::352) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Tue, 15 Dec 2020 16:24:20 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (2a01:111:e400:7e0c::52) by DB3EUR04FT033.mail.protection.outlook.com (2a01:111:e400:7e0c::78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.18 via Frontend Transport; Tue, 15 Dec 2020 16:24:20 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:B4A18799882A026CAD75594E8BDA724CF17941FA0F504740B9FA521B70E73BF7; UpperCasedChecksum:AD196E4E954B0E3E03D1A7F1D58E5DD53366E12A30E3DF28959A48528AA448C9; SizeAsReceived:9566; Count:48 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::184e:5e8c:db8f:a596]) by AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::184e:5e8c:db8f:a596%5]) with mapi id 15.20.3654.025; Tue, 15 Dec 2020 16:24:20 +0000 Subject: Re: [PATCH v2] Enable GDB build with in-tree GMP and MPFR To: Simon Marchi , Joel Brobecker , Simon Marchi Cc: Tom Tromey , Pedro Alves , Eli Zaretskii , Andrew Burgess , "gdb-patches@sourceware.org" 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> <4ea7575a-b727-d9b7-e510-5c8b942f77f9@polymtl.ca> From: Bernd Edlinger Message-ID: Date: Tue, 15 Dec 2020 17:24:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: <4ea7575a-b727-d9b7-e510-5c8b942f77f9@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TMN: [aeJOHMhBnbwG3m6wYtvyATZqRWEp5eHg] X-ClientProxiedBy: AM4PR0902CA0007.eurprd09.prod.outlook.com (2603:10a6:200:9b::17) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) X-Microsoft-Original-Message-ID: <4c086975-dc58-0347-f13b-e1bd1734e57f@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (88.68.3.2) by AM4PR0902CA0007.eurprd09.prod.outlook.com (2603:10a6:200:9b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Tue, 15 Dec 2020 16:24:20 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 4c2fa9ec-10bf-4469-e614-08d8a115e0ad X-MS-TrafficTypeDiagnostic: DB3EUR04HT127: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4e4NYW5vJb00q6aP/AlY5i4X8jNspXicuuIxrsKHtTXz9wfsQUIo6IjQz0J6WkeQt8+A5kgYFUEFyLxHLcY+w5m3duJCd2/Ab49Kpl3/gZsSR2d/vKaiXUYCjMddgZxgjd34MYYQ/blTASKKDGGX0GgkR4jePtsBu97EfCBN0WAZeQk4V1I2Hh66rRr2pIzTYuSAzvfQaaf/dQs2kFlKAQ== X-MS-Exchange-AntiSpam-MessageData: QAa3B/1dpDzc/uII5n73Iw2yKIbZHI5CPUZmzIwe/0rWDXEQRjxpVid0QvbkW7a91r2iwQ1boySeIz52RwW9OCsndL7WMBmYhf9TtQPON3DVBXZbalDN7XPYueIWGDX0NbmqYLO40U0Msme9hQlGaQ== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Dec 2020 16:24:20.7963 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-Network-Message-Id: 4c2fa9ec-10bf-4469-e614-08d8a115e0ad X-MS-Exchange-CrossTenant-AuthSource: DB3EUR04FT033.eop-eur04.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3EUR04HT127 X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, FORGED_MUA_MOZILLA, FREEMAIL_FROM, KAM_DMARC_STATUS, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 15 Dec 2020 16:24:24 -0000 On 12/15/20 3:39 PM, Simon Marchi wrote: > 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. > One thing, that might be useful here, is making the toplevel configure script print an error, when GMP is not available, instead of having the error later when gdb/configure runs. For instance when the toplevel configure detects gcc needs to be built, it checks the availability and correct versions if GMP/MPFR/MPC/ISL while it does nothing when gdb is built. My patch does not yet touch that logic, but it is probably a next logical step. >> 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 > Bernd.