From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kxPNGn3q6l+TWwAAWB0awg (envelope-from ) for ; Tue, 29 Dec 2020 03:36:13 -0500 Received: by simark.ca (Postfix, from userid 112) id 5CDED1E965; Tue, 29 Dec 2020 03:36:13 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: * X-Spam-Status: No, score=1.9 required=5.0 tests=FORGED_MUA_MOZILLA, FREEMAIL_FROM,MAILING_LIST_MULTI,MSGID_FROM_MTA_HEADER,RDNS_NONE 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 C3F161E965 for ; Tue, 29 Dec 2020 03:36:12 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DE7AE385801A; Tue, 29 Dec 2020 08:36:11 +0000 (GMT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-oln040092071023.outbound.protection.outlook.com [40.92.71.23]) by sourceware.org (Postfix) with ESMTPS id 64ABD3858006 for ; Tue, 29 Dec 2020 08:36:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 64ABD3858006 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=ABIXYgrDcuD293kkcGzzVDdU9GyftRhIbVLQp+3UeHEFCvXZg6vGwBx8zfUwUNN2iVootdHcpBaSSa77PZOjgf+LFmD3VWBFhM+QbJ2aNKNI3tUi96biMC3NU6LC30qhHM3dCTm5vC6ET225BGcUty4yqcLfU6oSfjC51pq07J+OFmA/hel+esMEOp00kznKOoS6KEx26n1yvMvGpIUZTNkodpAzbVFCiGhz0NCWcRJuPB6YvB4xKsicCGKppji3OF1mu6SexkqCRsEDY+1YtoW1OxKM3w8A881lWsbieBv9We6MltDs7Vy0HI6qwLxGR6zEPzPdm74HMANUj3evzA== 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=oQiCUcSS5AlBTl/QdcK3mqtYc5Am/LO1qC4AvA70H/o=; b=czPbsiIL293wHJ8edLE1jBoWyAPO5oj4D9gYTCyiBKHxgxYpQITuUwrmX9ZGArtvGaUwnAof8axJGKSa4XgNdFtcQAbTvF2CIgrou+TOKt8BKEmYSwNIZesGilUwttAMFrXX+W7zlTK1JKBvu9gHKJnHIjbn6SUkWAURyR/TM1qu34QcK8ul7iPk18ISzIajCbmngwnggsCxhGAL5SE0RXeHaGx8TMxyRq+cfHvny+b1KuSl6mKDxdYZQjws8bhnN5AT9Ainj3hh+SrGaLLJ1pnxhBG6TD58q4Sl8NM3LyjZdZ5+2pJsKmo1/GT/uOMB/LTVkIKfU/yJr6JyTY9cRg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from VE1EUR03FT038.eop-EUR03.prod.protection.outlook.com (2a01:111:e400:7e09::4b) by VE1EUR03HT043.eop-EUR03.prod.protection.outlook.com (2a01:111:e400:7e09::404) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.27; Tue, 29 Dec 2020 08:36:03 +0000 Received: from HE1PR0602MB3417.eurprd06.prod.outlook.com (2a01:111:e400:7e09::4a) by VE1EUR03FT038.mail.protection.outlook.com (2a01:111:e400:7e09::368) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.27 via Frontend Transport; Tue, 29 Dec 2020 08:36:03 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:3BC9E90BC9A1549D39404FF72F3A0C65F352C9870C44858B5AE106EAD40C8393; UpperCasedChecksum:A880D45CAD0B6B589F02C86944F9AE392B5C11F42EBCEEFF900F1E602FE7EC12; SizeAsReceived:8839; Count:48 Received: from HE1PR0602MB3417.eurprd06.prod.outlook.com ([fe80::f065:d534:d0c0:b294]) by HE1PR0602MB3417.eurprd06.prod.outlook.com ([fe80::f065:d534:d0c0:b294%6]) with mapi id 15.20.3700.031; Tue, 29 Dec 2020 08:36:03 +0000 Subject: Re: [PATCH v2] Enable GDB build with in-tree GMP and MPFR To: Simon Marchi , Joel Brobecker References: <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> <20201216073333.GA934694@adacore.com> <89e6d36b-7a4b-4eed-69bd-fa82add4dab0@polymtl.ca> From: Bernd Edlinger Message-ID: Date: Tue, 29 Dec 2020 09:36:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: <89e6d36b-7a4b-4eed-69bd-fa82add4dab0@polymtl.ca> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TMN: [67lKMNZTFsUSsj8lZh0uYhyccdiDAySP] X-ClientProxiedBy: AM0PR04CA0075.eurprd04.prod.outlook.com (2603:10a6:208:be::16) To HE1PR0602MB3417.eurprd06.prod.outlook.com (2603:10a6:7:80::17) X-Microsoft-Original-Message-ID: <203e073d-306f-dd63-aa03-5648386f0a1a@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (88.68.3.2) by AM0PR04CA0075.eurprd04.prod.outlook.com (2603:10a6:208:be::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.19 via Frontend Transport; Tue, 29 Dec 2020 08:36:01 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 3720c825-72ff-49a2-667e-08d8abd4c6d6 X-MS-TrafficTypeDiagnostic: VE1EUR03HT043: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xLm5/DI1F8Q8KKc9zQlFTEQ494GysakXGrBgFWB/eCWkK670jfJa/zYNW5Iva7NvMF8xWUA47SARZ/+j5DsnWINmMO7hXeVhWRW6rjN3EAcz2E7pr1pAfovIpqGb9WfW/CnTmRtsgHqF55groGbawvu2eiXRmQgxhPzwYnGSe1A2Jm76foWWqYFOkWCd39EeLL6muy1pMFa31gUVcpSCOxh1kZ70kdGCFacgscZ1OGssJh0oW6EpYcgQHTds3ZpQ X-MS-Exchange-AntiSpam-MessageData: UBaqEmeEsmfGDjU3lw83/hqoPAhPIvkqMctns811LFIaoeeQukqSV9ALQ+vvtLjtNirrkxrC/h1qGalk4KVIihZAVRsT92TSrr4AUtb5CMiwP1qqRX3/4VMa3T6fRUXNcEABV3cWmPVebYjVSc5txg== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Dec 2020 08:36:02.9531 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-Network-Message-Id: 3720c825-72ff-49a2-667e-08d8abd4c6d6 X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT038.eop-EUR03.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: VE1EUR03HT043 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: , Cc: Pedro Alves , Tom Tromey , "gdb-patches@sourceware.org" Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 12/27/20 11:01 PM, Simon Marchi wrote: > > > On 2020-12-25 7:05 a.m., Bernd Edlinger wrote: >> Hi everybody, >> >> I have now two possible ways to go forward with the configure options >> for gmp and mpfr. >> >> See the attached patches: >> >> Variant 1: implements traditional configure options >> --with-gmp-include=DIR, --with-gmp-lib=DIR, --with-gmp=DIR, >> --with-mpfr-include=DIR, --with-mpfr-lib=DIR, --with-mpfr=DIR >> but does additionally understand --with-libmpfr-prefix=DIR >> and --with-mpfr=auto/yes/no. >> >> Variant 2: (I already posted that one) keeps all configure options >> as they are now, and just uses the presence of a ../gmp and ../mpfr >> directory to override the gmp and mpfr configure flags. >> >> I would be interested in what you think, and which variant you would >> prefer. >> >> >> Thanks >> Bernd. >> > > I really don't have a strong opinion about this, but my only strong-ish > opinion is that I want to minimize the complexity of what we add. > I'm already on the fence about the download script and detecting gmp > / mpfr in-tree, because I think this is complexity we don't need. > It's not difficult for the user to download and build these two > libraries. It's totally fine for a project to have required > dependencies that the user needs to build first... > > We already provide --with-libmpfr-prefix and --with-libgmp-prefix. > Any complexity we add (like adding --with-gmp-include and > --with-gmp-lib on top of that) means more combinations to test for > whoever needs to modify that code next, more chances of breaking > something. IMO it is not a net benefit for the project to add > these additional new switches. > > Joel convinced me that it's not so important to stay in sync with > gcc for this. So I'd choose the existing solution of using > AC_LIB_HAVE_LINKFLAGS, since that takes care of all the low level > details for us. > > Simon > Okay, I also like the second variant better. Can I assume that you agree to that variant? If yes, then I should send the patch regarding the toplevel configury change also to the binutils mailing list, right? Thanks Bernd.