Prepare some build fixes in advance of more _FORTIFY_SOURCE

[kevans]

Summary

ZFS' libspl needs to be made aware that we have strlcat(3) and
strlcpy(3) to avoid some more complicated declaration duplication, so
go ahead and define these HAVE_ macros now.

While we're here, make sure that we disable _FORTIFY_SOURCE in the
bootloader because we don't have the symbol renaming support today to do
it as cleanly as we'd like. ssp/ssp.h needs to be pulled into the libsa
environment so that other bits can understand that ssp is disabled in
the consistent __SSP_FORTIFY_LEVEL way that we try to do.

Sponsored by: Stormshield
Sponsored by: Klara, Inc.

[allanjude]

ZFS bits look good to me

[markj]

include/ssp/ssp.h

39 ↗

(On Diff #140077)

Why is this needed? I'd assume that this file is never included in kernel builds since it lives under include/.

[kevans]

include/ssp/ssp.h

39 ↗

(On Diff #140077)

Ah, I forgot to revisit this. Thinking about it, this was probably an artifact of an incorrect conditional in one of the kernel headers that have some fortified bits in them. I think they all look fine now, so this likely just goes away.

[kevans]

Push exclusion of _KERNEL out of ssp/ssp.h, we just shouldn't see
_FORTIFY_SOURCE > 0 there ever. Fix the problem in libprocstat instead, which
includes the following verbiage added to the commit message:

libprocstat has to define `_KERNEL` and include kernel headers in order
to get what it wants, but this results in sys/cdefs.h being included too
late and we pick up the build breaking version of the __RENAME
definition.  Just explicitly include sys/cdefs.h earlier rather than
disabling _FORTIFY_SOURCE.  The zfs/ subdir only builds an object that
holds some structures and sizes, so just disable _FORTIFY_SOURCE there
entirely rather than trying to move #define _KERNEL into the file..