From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11441 invoked from network); 20 Nov 2003 15:23:35 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 20 Nov 2003 15:23:35 -0000 Received: (qmail 65 invoked by alias); 20 Nov 2003 15:23:29 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19263 Received: (qmail 4 invoked from network); 20 Nov 2003 15:23:28 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 20 Nov 2003 15:23:28 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [199.185.220.222] by sunsite.dk (MessageWall 1.0.8) with SMTP; 20 Nov 2003 15:23:28 -0000 Received: from whaite.ca ([142.169.175.21]) by priv-edtnes12-hme0.telusplanet.net (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP id <20031120152326.LZPD16941.priv-edtnes12-hme0.telusplanet.net@whaite.ca>; Thu, 20 Nov 2003 08:23:26 -0700 Message-ID: <3FBCDC62.3080209@whaite.ca> Date: Thu, 20 Nov 2003 10:23:14 -0500 From: Peter Whaite User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zsh-workers@sunsite.dk CC: Clint Adams Subject: Re: Freebsd configure misses and References: <3FBAC7A4.2080505@whaite.ca> <20031119185911.GA15117@scowler.net> In-Reply-To: <20031119185911.GA15117@scowler.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Clint Adams wrote: >>For some time now I have been trying to compile CVS zsh on a freebsd >>machine. It fails on Src/Modules/terminfo.c >> >> > >I have a similar problem on FreeBSD 4.8. What's happening in my case is >that configure finds libtinfo (which, along with libtermcap and >libcurses, is just a symlink to libncurses), thus the >case "$LIBS" in *curses*) fails. > >--with-curses-terminfo doesn't help because tinfo is still preferred. > > Yes that is it -- /usr/lib/libtinfo* links to libncurses*. I see in other threads that #defining ERR has been proposed for other reasons. I guess that will fix it, but still leave the implicit declaration warnings. Seems it would be better to fix configure, assuming this libtinfo link thing is something reasonably "standard".