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@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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
