svn commit: r247683 - head/lib/libedit

[Jilles Tjoelker]

On Sun, Mar 03, 2013 at 02:43:14PM +0100, Jilles Tjoelker wrote:
> On Sun, Mar 03, 2013 at 02:11:04AM +0000, Pedro F. Giffuni wrote:
> > Author: pfg
> > Date: Sun Mar  3 02:11:03 2013
> > New Revision: 247683
> > URL: http://svnweb.freebsd.org/changeset/base/247683

> > Log:
> >   libedit does not need to be linked with ncurses

> >   libedit uses the terminfo headers but doesn't really need
> >   to be linked with ncurses.

> >   Discussed with:		christos at NetBSD
> >   MFC after;		3 days

> > Modified:
> >   head/lib/libedit/Makefile
> 
> > Modified: head/lib/libedit/Makefile
> > ==============================================================================
> > --- head/lib/libedit/Makefile	Sun Mar  3 01:36:31 2013	(r247682)
> > +++ head/lib/libedit/Makefile	Sun Mar  3 02:11:03 2013	(r247683)
> > @@ -11,7 +11,6 @@ OSRCS=	chared.c common.c el.c emacs.c fc
> >  	parse.c prompt.c read.c refresh.c search.c sig.c term.c tty.c vi.c
> >  
> >  DPADD=	${LIBNCURSES}
> > -LDADD=	-lncurses
> >  
> >  MAN=	editline.3 editrc.5
> >  

> This is wrong. libedit.so uses symbols such as tgetent from
> libcurses.so, so it should be linked to libcurses.so. These symbols are
> easily visible in the output of
>   objdump -T /lib/libedit.so.7
> because they are unversioned.

> There is not much breakage because most applications using libedit
> explicitly link to libcurses, since that is required for static linking.
> For dynamic linking it is really a case of overlinking, particularly
> because libedit completely abstracts away libcurses from the
> application's point of view (in other words, the application need not
> call libcurses itself).

This actually happens in buildworld, so I have taken the liberty to
revert your commit.

-- 
Jilles Tjoelker