From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9856F3858405 for ; Fri, 22 Jul 2022 20:35:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9856F3858405 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-359-n0Rnm7KOOWiWwW9cwgmhtw-1; Fri, 22 Jul 2022 16:35:25 -0400 X-MC-Unique: n0Rnm7KOOWiWwW9cwgmhtw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A179D803520; Fri, 22 Jul 2022 20:35:24 +0000 (UTC) Received: from [10.2.16.251] (unknown [10.2.16.251]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5E415C28100; Fri, 22 Jul 2022 20:35:24 +0000 (UTC) Message-ID: <197286b6-4529-181a-13e4-a6a9a88db204@redhat.com> Date: Fri, 22 Jul 2022 13:35:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] configure: exit with an error if no termcap lib is installed To: Christophe Lyon , gdb-patches@sourceware.org References: <20220721085124.76878-1-christophe.lyon@arm.com> From: Keith Seitz In-Reply-To: <20220721085124.76878-1-christophe.lyon@arm.com> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Fri, 22 Jul 2022 20:35:29 -0000 Hi, On 7/21/22 01:51, Christophe Lyon via Gdb-patches wrote: > The termcap detection code in aclocal.m4 (BASH_CHECK_LIB_TERMCAP) > defaults to "gnutermcap" if none of the usual libraries is available > (termcap, tinfo, curses, ncurses, ncursesw). > > Then it sets TERMCAP_LIB to "./lib/termcap/libtermcap.a", so it > expects that libtermcap.a is present under lib/termcap in the build > directory. > > In fact, this is generally not the case (we do not manually install > libtermcap in the build tree), so it's better to stop with an error > message. Thanks for the patch! I've been bitten by this once or twice, so I welcome this change. Kudos, too, for following the documented procedure and updating readline/README. Just two quick questions. Regarding the patch itself, my (admittedly hasty) reading of BASH_CHECK_LIB_TERMCAP (in aclocal.m4) is that if "--with-curses" is supplied and is not available, bash_cv_termcap_lib will (also) be set to "gnutermcap". [More pedantically, if *no* satisfactory library was found.] The following if .. elif .. blocks essentially ignore "gnutermcap" when "prefer_curses" is set, and the code falls through to the final "else," setting "TERMCAP_LIB=-lcurses". Back in configure.ac, we have > @@ -6367,7 +6367,7 @@ if test "$TERMCAP_LIB" = "./lib/termcap/libtermcap.a"; then > if test "$prefer_curses" = yes; then > TERMCAP_LIB=-lcurses > else > - TERMCAP_LIB=-ltermcap #default > + as_fn_error $? "missing required termcap lib or equivalent" "$LINENO" 5 > fi > fi I don't see how we can get TERMCAP_LIB set to "./lib/termcap/libtermcap.a" and have prefer_curses. That appears to be dead code. However, I think this still misses issuing the error when --with-curses is supplied. Naively, one well-placed AC_MSG_ERROR should do it, but maybe readline developers have a reason to do this? Having said that, have you attempted to get this patch merged upstream? Above questions aside, in the long run, it would be best to get this merged there. That would greatly reduce the burden of maintaining/carrying/merging these local patches. Keith