From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id CMKvOnUg2F8zdgAAWB0awg (envelope-from ) for ; Mon, 14 Dec 2020 21:33:25 -0500 Received: by simark.ca (Postfix, from userid 112) id EDB361F0AA; Mon, 14 Dec 2020 21:33:25 -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.3 required=5.0 tests=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 908681E590 for ; Mon, 14 Dec 2020 21:33:25 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CB5AD385800D; Tue, 15 Dec 2020 02:33:24 +0000 (GMT) Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTP id 27487385800D for ; Tue, 15 Dec 2020 02:33:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 27487385800D 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 EBA745612E; Mon, 14 Dec 2020 21:33:21 -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 ofkqp22tWJUY; Mon, 14 Dec 2020 21:33:21 -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 6294656114; Mon, 14 Dec 2020 21:33:21 -0500 (EST) Received: by float.home (Postfix, from userid 1000) id CA437A1916; Tue, 15 Dec 2020 06:33:15 +0400 (+04) Date: Tue, 15 Dec 2020 06:33:15 +0400 From: Joel Brobecker To: Simon Marchi Subject: Re: [PATCH v2] Enable GDB build with in-tree GMP and MPFR Message-ID: <20201215023315.GK3461@adacore.com> References: <20201118034455.GE617116@adacore.com> <71f5437f-c4f5-b58d-06f7-67a4d0b31007@simark.ca> <214e9564-5dfd-65a2-c2d8-6e8398ebc913@simark.ca> <87o8iw9ilx.fsf@tromey.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: Pedro Alves , Bernd Edlinger , Tom Tromey , "gdb-patches@sourceware.org" Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" > >>>>>> "Simon" == Simon Marchi writes: > > > > Simon> So with this patch, we now have: > > > > Simon> --with-gmp-include=DIR GMP include directory > > Simon> --with-gmp-lib=DIR GMP lib directory > > Simon> --with-gmp=DIR GMP install directory > > Simon> --with-libgmp-prefix[=DIR] search for libgmp in DIR/include and DIR/lib > > Simon> --without-libgmp-prefix don't search for libgmp in includedir and libdir > > > > Simon> I think that's getting a bit confusing. That's too many ways to set gmp > > Simon> paths, with -with-libgmp-prefix and --with-gmp doing the same thing. > > > > FWIW we have the same situation with MPFR. > > :( Yeah, my reaction exactly when Bernd made me discover this problem. There might be other options in the same category; we should double-check (busy this week, but I can have a look during the weekend if noone beats me to it). > > 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. 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. 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? So, as you can see, the question is much larger than just GMP/MPFR. > > Simon> An alternative to downloading the pre-requisites would be to check them > > Simon> in the repo. We do it for readline already: there is a copy in the > > Simon> repo, which is used by default, but you can specify > > Simon> --with-system-readline if you want to use the system's readline. We > > Simon> could do the same with gmp and mpfr. The downside is that we deviate a > > Simon> bit from how gcc does, the the upside is that it's simpler, IMO. > > > > For me the main difference here is that, historically, we've had to > > patch readline. In cases where GDB has never needed to patch a > > dependency (libiconv comes to mind), we've haven't bothered. > > Ok, when you put it like that then it doesn't make as much sense to > check the code in the repo. > > Thinking about it a bit more, I don't see why gmp and mpfr get this > treatment, what is it that makes them different from other dependencies? > If you want to build GDB with XML support, you download and build expat, > or install it using your package manager. Why can't you do the same > with mpfr/gmp? The only reason for us I can see is "because gcc does > it" and we share the build system with gcc. But otherwise, I'd just > tell people to build/install mpfr and gmp themselves. > > Simon -- Joel