From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id iOtGGOj+sV+5VAAAWB0awg (envelope-from ) for ; Sun, 15 Nov 2020 23:24:08 -0500 Received: by simark.ca (Postfix, from userid 112) id 5D7B11F08B; Sun, 15 Nov 2020 23:24:08 -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.0 required=5.0 tests=MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [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 07B311E58D for ; Sun, 15 Nov 2020 23:24:08 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 506203857023; Mon, 16 Nov 2020 04:24:07 +0000 (GMT) Received: from rock.gnat.com (rock.gnat.com [IPv6:2620:20:4000:0:a9e:1ff:fe9b:1d1]) by sourceware.org (Postfix) with ESMTP id 010273857C69 for ; Mon, 16 Nov 2020 04:24:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 010273857C69 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=brobecker@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B58871161D1; Sun, 15 Nov 2020 23:23:34 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jmETaitDA90I; Sun, 15 Nov 2020 23:23:34 -0500 (EST) Received: from float.home (localhost.localdomain [127.0.0.1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id 58D571161AB; Sun, 15 Nov 2020 23:23:33 -0500 (EST) Received: by float.home (Postfix, from userid 1000) id 7A8FFA1870; Mon, 16 Nov 2020 07:45:18 +0400 (+04) Date: Mon, 16 Nov 2020 07:45:18 +0400 From: Joel Brobecker To: Bernd Edlinger Subject: Re: [pushed/v2 1/9] gdb/configure: Add --with-libgmp-prefix option Message-ID: <20201116034518.GA609903@adacore.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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" 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. 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. 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. 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 ? -- Joel