Fix "make checkdpadd" for libc when MK_SSP != no and fix libncurses-related "make checkdpadd" issues

[ngie]

Summary

Fix "make checkdpadd" for libc when MK_SSP != no and fix libncurses-related "make checkdpadd" issues

Review note: this diff is a combination of the 2 PRs because there's
overlap in bsd.libnames.mk; they will be committed separately

PR 192728 related changes:

• LIBSSP_NONSHARED is introduced in bsd.libnames.mk
• LIBSSP_NONSHARED is added to DPADD in lib/libc when MK_SSP == no

PR 192762 related changes:

• LIBCURSES is removed in favor of LIBNCURSES:
  • A string literal is added to bsd.libnames.mk, similar to other

libraries that have been removed with a message noting the required
conversion

• • All consumers in the base system have been converted to LIBNCURSES*
• LIBTERMCAPW is introduced to fix "make checkdpadd" issues with

components that depend on its definition

PR: 192728, 192762
MFC after: 1 week

[rpaulo]

What's the rationale behind the move from LIBCURSES TO LIBNCURSES?

[ngie]

In D675#5, @rpaulo wrote:

What's the rationale behind the move from LIBCURSES TO LIBNCURSES?

1. LIBCURSES is the old way of describing LIBNCURSES.
2. libcurses* is an alias for libncurses*

$ egrep -r 'LIB\??=' lib/ncurses/
lib/ncurses/panel/Makefile:LIB= panel${LIB_SUFFIX}
lib/ncurses/ncurses/Makefile:LIB=               ncurses${LIB_SUFFIX}
lib/ncurses/form/Makefile:LIB=  form${LIB_SUFFIX}
lib/ncurses/menu/Makefile:LIB=  menu${LIB_SUFFIX}

from lib/ncurses/ncurses/Makefile:

.if ${MK_INSTALLLIB} != "no"
SYMLINKS+=      libncurses${LIB_SUFFIX}.a ${LIBDIR}/libcurses${LIB_SUFFIX}.a
SYMLINKS+=      libncurses${LIB_SUFFIX}.a ${LIBDIR}/libtermcap${LIB_SUFFIX}.a
SYMLINKS+=      libncurses${LIB_SUFFIX}.a ${LIBDIR}/libtermlib${LIB_SUFFIX}.a
SYMLINKS+=      libncurses${LIB_SUFFIX}.a ${LIBDIR}/libtinfo${LIB_SUFFIX}.a
.endif
.if !defined(NO_PIC)
# no need for major at all, it's an ld-time redirection only
SYMLINKS+=      libncurses${LIB_SUFFIX}.so ${LIBDIR}/libcurses${LIB_SUFFIX}.so
SYMLINKS+=      libncurses${LIB_SUFFIX}.so ${LIBDIR}/libtermcap${LIB_SUFFIX}.so
SYMLINKS+=      libncurses${LIB_SUFFIX}.so ${LIBDIR}/libtermlib${LIB_SUFFIX}.so
SYMLINKS+=      libncurses${LIB_SUFFIX}.so ${LIBDIR}/libtinfo${LIB_SUFFIX}.so
.endif
.if ${MK_PROFILE} != "no"
SYMLINKS+=      libncurses${LIB_SUFFIX}_p.a ${LIBDIR}/libcurses${LIB_SUFFIX}_p.a
SYMLINKS+=      libncurses${LIB_SUFFIX}_p.a ${LIBDIR}/libtermcap${LIB_SUFFIX}_p.a
SYMLINKS+=      libncurses${LIB_SUFFIX}_p.a ${LIBDIR}/libtermlib${LIB_SUFFIX}_p.a
SYMLINKS+=      libncurses${LIB_SUFFIX}_p.a ${LIBDIR}/libtinfo${LIB_SUFFIX}_p.a
.endif

This email exchange I had with brooks@ might help add some context too for the change (although I realize now that I should change all users of LIBNCURSES to LIBNCURSESW, like clang, gstat, etc):

On Sun, Aug 17, 2014 at 05:45:15PM -0700, [e-mail] wrote:
Hi Bruce and -toolchain@!
	Are there any pitfalls foreseen with replacing LIBCURSES with LIBNCURSES and removing LIBCURSES from bsd.libnames.mk?
	While investigating "make checkdpadd? errors for PR 192762 ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192762 ), I noticed that some of the Makefiles referenced LIBCURSES* while the bulk majority referenced LIBNCURSES*. libcurses* is symlinked to libncurses* though:

# ls -l /usr/lib/libcurses*
lrwxr-xr-x  1 root  wheel  12 Aug 16 19:08 /usr/lib/libcurses.a -> libncurses.a
lrwxr-xr-x  1 root  wheel  13 Aug 16 19:08 /usr/lib/libcurses.so -> libncurses.so
lrwxr-xr-x  1 root  wheel  13 Aug 16 19:08 /usr/lib/libcursesw.a -> libncursesw.a
lrwxr-xr-x  1 root  wheel  14 Aug 16 19:08 /usr/lib/libcursesw.so -> libncursesw.so

	I don?t have a full history for why there?s a discrepancy between the two because it predates me (I assume it has to deal with moving from BSD curses to ncurses though...), but LIBCURSES has been around for quite a while ( http://svnweb.freebsd.org/base/head/share/mk/bsd.prog.mk?annotate=1639&pathrev=18052 ).

In head any users of LIBCURSES or LIBNCURSES are bugs as everything
should be linking to the W variants.  I think we've also mostly
eliminated uses of LIBCURSESW and I suspect that doing it in is the right
approach.

-- Brooks

[ngie]

I'll commit the change to convert everything over in the base system from LIBCURSES to their LIBNCURSES counterparts because it's functionally a no-op as I showed in my reply to rpaulo's comment above.

I'm going to hold off on deprecating LIBCURSES in bsd.libnames.mk because there are some pieces in the ports tree that require it in order to compile/link (editors/hexpert and net/nifmon at least). I'll open bugs for those ports so they so they get converted over, and open up a bug for portmgr to do an -exp run on the patch to figure out whether or not there are more issues with deprecating this variable. Once all of the issues have been resolved, I'll post a patch in a new phabric review to a) deprecate the value, and b) add an UPDATING entry for it.

Converting everything over to their wide library variants requires additional testing (it's not a no-op; the text segment for the wide-character variant of libncurses is ~50kB), so I would rather write up the testcases in ATF and backport the testcases with the wide library change after more extensive testing is done just to make sure that things are ok.

[ngie]

LIBCURSES has not been deprecated as previously discussed, but the other items seen in this PR have been resolved via r270519, r270650, and r270651. I'll open another review for deprecating LIBCURSES once all of the known issues with LIBCURSES have been resolved.