r253839 (stop recursively copying DT_NEEDED entries) and devel/ncurses

[Raphael Kubo da Costa]

<http://svnweb.freebsd.org/base?view=revision&revision=253839> has made
ld(1) stop copying DT_NEEDED entries from shared libraries, which brings
us in line with what most of the Linux world has been doing for a while
and is a Good Thing (TM) since we stop adding implicit dependencies to
our binaries.

I've noticed one possible regression with devel/ncurses, though: most of
the time, simply passing -lncurses or -lncursesw to the linker like most
ports do will not work, since one also needs to pass -ltinfo or -tinfow.
This happens because we build devel/ncurses with --with-termlib (which
causes libtinfo{w}.so to be generated).

I guess this was not detected in exp-runs because devel/ncurses is not
normally pulled by ports with USES=ncurses (if a port is being built in
a chroot, Uses/ncurses.mk will just check that base's ncurses is
installed and ${LOCALBASE}/lib/libcurses.so does not exist and move on).

This can be easily tested by passing USES=ncurses:port to any port that
has USES=ncurses (such as devel/tig, security/pinentry or shells/zsh)
or, like in my case, just happening to have devel/ncurses installed
because x11/rxvt-unicode needs it.

On the Linux distributions I checked (Arch Linux, openSUSE and Ubuntu),
either ncurses was not build with --with-termlib (so libncurses{w}.so
would provide all the required symbols) or they have some multiarch
setup in place so that /usr/lib/<arch>-linux-gnu/libncurses{w}.so is an
ld script that has something like

   INPUT(libncurses{w}.so AS_NEEDED(libtinfo{w}.so))

that solves the problem.

Right now, I'm not sure the best way to fix this is to patch each port
manually or stop passing --with-termlib in devel/ncurses.