From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id INJbArSKsl+xYAAAWB0awg (envelope-from ) for ; Mon, 16 Nov 2020 09:20:36 -0500 Received: by simark.ca (Postfix, from userid 112) id E281E1F08B; Mon, 16 Nov 2020 09:20:35 -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, 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 C7E991E58F for ; Mon, 16 Nov 2020 09:20:31 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 299883958C37; Mon, 16 Nov 2020 14:20:31 +0000 (GMT) Received: from EUR06-VI1-obe.outbound.protection.outlook.com (mail-vi1eur06olkn2061.outbound.protection.outlook.com [40.92.17.61]) by sourceware.org (Postfix) with ESMTPS id A5D4A3857C61 for ; Mon, 16 Nov 2020 14:20:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A5D4A3857C61 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=FgnUQzWClD4spVnXaJCzkvIVxErYnLVPCU8PDeBzos6VYD4857JuxmXe8JCGLXJ+XsFbIBLPDhclrBYuygmyBjTeUVjyYVsCNL1Eq/WpLE4TtSTTBoedyb77jlYFX6MrR7X1zRlDIfXtdiWuXrhrPvSllkIczmrnnKxddY4VoigBaFJkTExFWIf74eiOzjYgSOvKrwXt5nP6Q0FN7oOMj31xjbGVmLfa4gVErlsqnDGuJFStoOGIYca5s+PB0T6LLjcSu7GaQWjyjrjJUgH5oC4EALaDSX0QFwlNCV+SuVYnNtXK6wRipmdNDL1/twYLcV2EN8iPkRu1g/GLXdJPvw== 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=KKdwdJa2eN3XYENFW8Jl69vulWVLTCcDTXtOErT4c9o=; b=jG+cMcqPaUbXA5G0nnHJysnHp1R6FgrjnkvUTVyiq0eBc8/ZL8rrHiymUzmV7cYMjWgsl6tn7TXTChmypd7T242lNRSFDf3Yzra5tqKLpo0xZpGoAwb54y3wTOwtkV9l/PsOsmKDf6hnbjawNuyASwvg7wz5H0MK8EgiLSyq3RQJI4bj/uPgYKOhV/k7Crf58NUHzDFUmGZ+sv5TRWTFIb1Xk93TleTA5xrPyt7zIawDDXATY0CcQOdFvyLrM10JF63iOVIdF7UGwbjDbmgFU8p+FWt0L41k5TrGih1nEq+R+mWPdAxfhsDXewbLOoqqB4LfIiZeY5JZRNGFGcH7DQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from VI1EUR06FT013.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc37::40) by VI1EUR06HT214.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc37::379) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.22; Mon, 16 Nov 2020 14:20:24 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (2a01:111:e400:fc37::49) by VI1EUR06FT013.mail.protection.outlook.com (2a01:111:e400:fc37::116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.22 via Frontend Transport; Mon, 16 Nov 2020 14:20:24 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:27703D508A7DB17AECFF4420B8CA1003229979E9C875303D91882E847C66D8FF; UpperCasedChecksum:3B4F3FC7171A6F23E448F62AA5463489FB97D7636EBF6A46A204A8C6258443DC; SizeAsReceived:8115; 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.3564.028; Mon, 16 Nov 2020 14:20:24 +0000 Subject: Re: [pushed/v2 1/9] gdb/configure: Add --with-libgmp-prefix option To: Joel Brobecker References: <1604817017-25807-1-git-send-email-brobecker@adacore.com> <1605429345-78384-1-git-send-email-brobecker@adacore.com> <1605429345-78384-2-git-send-email-brobecker@adacore.com> <20201116034518.GA609903@adacore.com> From: Bernd Edlinger Message-ID: Date: Mon, 16 Nov 2020 15:20:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: <20201116034518.GA609903@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TMN: [NYY+a3yV8iwJLyGb06DlDpMRHYdsTjgV] X-ClientProxiedBy: AM0PR02CA0075.eurprd02.prod.outlook.com (2603:10a6:208:154::16) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) X-Microsoft-Original-Message-ID: <8a98662a-069b-638b-e180-e94e4c4ce124@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (84.57.57.184) by AM0PR02CA0075.eurprd02.prod.outlook.com (2603:10a6:208:154::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25 via Frontend Transport; Mon, 16 Nov 2020 14:20:23 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: ee34c2d2-8112-4dae-bdef-08d88a3ac20f X-MS-TrafficTypeDiagnostic: VI1EUR06HT214: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4sHB0ucZZek6bb30oRbh60MWVyZTJ+jqwRxY42aO+X5dRVas+i7wGqkaav0kinRnniytlW0iDijhfRZCDIY0zfgn9mhG8Z8DYzdu42XdFv3fEVd3Ktu+sbLzOklYmIGujDQHD/FYcc1dpewBY6SZoRSxw6UWFe0/eiDFdez+5VLhnzQbm+V3EwAxac5ZZX3N7YD8tLSuu+3jxjMoidvBqw== X-MS-Exchange-AntiSpam-MessageData: aGbZQ1iHghNGAlhqyT+KvR4A4orgTzFo4rAujZPwTRlcD4uXd5hS6qGFz6pFOJ0nis08PBPa/XKJCNxgVoqpUMf7v3ffJ/uNfjDVRzhBawutj0L33FehAbAZVEgbeva7z+by1Bs3qx+3RgzsfNzIBw== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee34c2d2-8112-4dae-bdef-08d88a3ac20f X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2020 14:20:24.5150 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: VI1EUR06FT013.eop-eur06.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: VI1EUR06HT214 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: Simon Marchi , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 11/16/20 4:45 AM, Joel Brobecker wrote: > Hi Bernd, > >> I noticed that this does not allow to build gmp in-tree like it is >> possible for gcc. I tried to overcome this by the attached patch. > > Indeed. It's not something I had considered. > >> While doing so, I also noticed an incompatibility with the top level >> configure stript, which advertises, and passes -with-gmp-include >> and -with-gmp-lib if in-tree gmp is found. >> >> So the --with-libgmp-prefix is not that the top level configure >> script suggests: >> >> $ ./configure --help | grep gmp >> --with-gmp-dir=PATH this option has been REMOVED >> --with-gmp=PATH specify prefix directory for the installed GMP >> --with-gmp-include=PATH/include plus >> --with-gmp-lib=PATH/lib >> --with-gmp-include=PATH specify directory for installed GMP include files >> --with-gmp-lib=PATH specify directory for the installed GMP library >> >> What do you think, can we allow these traditional configure options >> additional to the new --with-libgmp-prefix? > > Can you check if these options are actually used elsewhere in > the binutils-gdb project? The idea I have in the back of my mind > is to see whether we can use the same options as the ones we've been > using in GDB or not. The fact that we have an AC_LIB_HAVE_LINKFLAGS > macro which takes care of handling dependencies for us tells me > that we are transitioning away from the model above where we add > the options "by hand" in configure.ac, and instead rely on the new > macro. > I think they are also used as configuration options in mpfr and mpc, and understood by the top level configuration. $ mpc-1.0.3/configure --help [...] --with-mpfr-include=DIR MPFR include directory --with-mpfr-lib=DIR MPFR lib directory --with-mpfr=DIR MPFR install directory --with-gmp-include=DIR GMP include directory --with-gmp-lib=DIR GMP lib directory --with-gmp=DIR GMP install directory [...] $ [...] --with-gmp-include=DIR GMP include directory --with-gmp-lib=DIR GMP lib directory --with-gmp=DIR GMP install directory --with-gmp-build=DIR GMP build directory (please read INSTALL file) [...] > One thing I did note is that GDB has some options for MPFR support > and in particular, it has --with-mpfr: > > --with-mpfr include MPFR support (auto/yes/no) > > As you can see, the --with-gmp option you propose is not consistent > with the above. > Hmm, yes, indeed, the --with-mpfr seems to be hand-crafted, since there is currently no --with-gmp=[auto/yes/no], (neither before or after my patch). I think the --with-mpfr might probably cause problems with mpc in-tree build, if that ever happens. Of course the this mpfr support does not work with in-tree mpfr either. For that to work we would need at minimum --with-mpfr-include=DIR and --with-mpfr-lib=DIR or equivalent, however mpfr is probably not worth the effort. > Unfortunately, in digging further, I found that toplevel configure > *also* has --with-mpfr, with a different meaning: > > --with-mpfr=PATH specify prefix directory for installed MPFR package. > Equivalent to --with-mpfr-include=PATH/include plus > --with-mpfr-lib=PATH/lib > > The way we expect people to configure GDB is to configure it as > part of the binutils-gdb project, so I don't see how GDB's --with-mpfr > could work, unless the top-level configury is more elaborate than > I remembered. > > Depending on the above, perhaps it might be better to actually > to change the top-level configury to advertise the --with-gmp-prefix > options instead of adding parallel support for the old-style > options in GDB's configury. And while at it, perhaps start deprecating > the old-style ones in the top-level configury. > Of course there is still mpfr's --with-gmp=DIR configuration option. But there may also be other surprises like this in configure.ac : *-*-freebsd*) if test "x$with_gmp" = x && test "x$with_gmp_dir" = x \ && ! test -d ${srcdir}/gmp \ && test -f /usr/local/include/gmp.h; then with_gmp=/usr/local fi ;; as you see, this option was already there for a while. > One more note: For me, I think we can handle the question of > in-tree building independently of the question of the configury's > options -- which is good, because I think the latterm might require > a bit of discussion. > >> Can we the top level Makefile.def change in binutils-gdb or has this >> be checked-in first in gcc? > > That's a good question. I *think* that binutils + GDB now have > ownership, but I might be wrong. Hopefully others know better. > If not, I will ask. > >> 2020-11-15 Bernd Edlinger >> >> * Makefile.def: Prepare for GDB build with intree GMP. >> * Makefile.in: Regenerate. >> >> gdb: >> 2020-11-15 Bernd Edlinger >> >> * configure.ac: Add --with-gmp= --with-gmp-include= and --with-gmp-lib= >> for compatibility with top level configure script. >> * configure: Regenerate. > > Looking at your patch, I'm wondering how this would all fit together... > Would it all work automatically (like it does for libiconv, I believe), > or where you planning on having to pass --with-gmp options ? > No, all it needs, is a symlink named "gmp" pointing to gmp's source tree, in the top level directory, like gcc's contrib/download_prerequisites does. Once the gmp directory is there the --with-gmp-include and --with-gmp-lib options are passed to in-tree mpfr if any, and now additionally to gdb. The --with-gmp=DIR option itself is not needed at all for the in-tree build. Bernd.