[Apologies for not giving more notice/warning about turning on
 FORTIFY_SOURCE for some system libraries at the time of my commit; it's
 clear to me now that the implications for 3rd-party code were considerably
 greater than I mistakenly expected]

A few days ago, I turned on the "fortify source" (argument length checking
on memory and string copy and set functions) for those system libraries
which handle network data or have a history of data-driven bugs (or, of
course, in many cases, both).  For various technical reasons I didn't
turn it on for libc, but this didn't limit the scope of the resulting
inter-library dependencies on libssp as much as one might think.

For dynamic libraries, the dependencies don't cause any problem: they
are automatically handled by the runtime linker.  But for programs that
are statically linked to a library which was built with FORTIFY_SOURCE,
this imposes a requirement to link to libssp.  This kind of implicit
dependency between static libraries is one reason an increasing number
of Unixy operating systems have deprecated static linkage, but though
NetBSD links the whole system static by default, that would be a rather
dramatic step to take at this time.

The issue shows up most obviously as undefined symbols in programs in
pkgsrc that build with -static (though they often don't need to).

After examining the problem at a bit more length I think the right
solution is to move the FORTIFY_SOURCE support we currently have in
libssp into libc.  The increase in size of the dynamic libc will be
approximately 8 kilobytes, and, of course, static programs that don't
use the functions in question won't grow at all.

It is in fact the case that all the functions we have in our libssp
are *already* in libc in the other operating systems that build with
FORTIFY_SOURCE turned on by default (e.g. RedHat Enterprise).  So from
a namespace point of view this should make us closer to others, not
farther from it.  I can retain libssp.so as another name for libc.so
for compatibility with old dynamically linked executables.

The breakage for static programs is frustrating to pkgsrc users and so
I intend to actually make this change within the next few days.  Does
anyone have a convincing reason why I shouldn't, particularly considering
that these functions are already in libc, not libssp, in other Unices?

Here is a list of the libraries currently dependent on libssp, FWIW:

libasn1 libbluetooth libbz2 libc libcrypto libdes libgssapi libhdb
libipsec libiscsi libkadm5clnt libkadm5srv libkafs libkrb5 libkvm
libmagic libpam libpcap libpuffs libradius librefuse librmt librpcsvc
libipsec libiscsi libkadm5clnt libkadm5srv libkafs libkrb5 libkvm
libmagic libpam libpcap libpuffs libradius librefuse librmt librpcsvc
libsdp libskey libsl libss libssl libtelnet libwrap libz

Thor