Test compiled on i386 and amd64; there may be some stragglers
on other platforms.
Note: -Wall has this by default in gcc4, and we explicitly disable it at
WARNS=1 (i.e., -Wall -Wno-sign-compare). A goal is to reduce the WARNS level
where this feature is enabled, so we can eventually remove -Wno-sign-compare.
Previously, they were defined in bsd.own.mk if USETOOLS=yes, but in
bsd.sys.mk if USETOOLS!=yes. This caused makefiles that did this:
.include <bsd.own.mk>
FOO != ${TOOL_BAR} args...
to work in the USETOOLS=yes case but not in the USETOOLS!=yes case.
set to /usr/bin/bash if HOST_CYGWIN was defined, but now build.sh
tries to set HOST_SH appropriately.
Remove the HOST_CYGWIN variable, which was not used for any other purpose.
Document that HOST_SH should be an absolute path.
THis was proposed in tech-toolchain.
In bsd.README, document all TOOL_* variables that are set in bsd.sys.mk.
There are several TOOL_* variables that are set in bsd.own.mk, but not
set in bsd.sys.mk and not documented in bsd.README.
* in games/fortune/strfile/Makefile, build strfile as a
regular program instead of as a host tool;
* add tools/strfile directory to build strfile as a host tool;
* in tools/Makefile, add strfile to SUBDIR list;
* in BSD.*.mk, define TOOL_STRFILE variable;
* in games/fortune/datfiles/Makefile, use TOOL_STRFILE when creating
databases at build time;
* in distrib/sets/lists/games/mi, mention usr/games/strfile.
-Wa,--fatal-warnings
to CFLAGS to set assembler warnings to be fatal.
(Done via CFLAGS instead of AFLAGS so that all assembling, not just
that of .S/.s files, uses the option.)
> Don't make linker warnings fatal on linking static libs since
> there is no proper way to avoid "FOO is a patented algorithm" warnings.
Ok'ed by christos@ and dogcow@ on tech-toolchain, and
tested build.sh build for sun2, news68k, alpha and newsmips.
include path: the normal header files now include the "SSP" ones (which one
should note are not really named right: SSP and FORTIFY_SOURCE are independent
features).
Disable USE_SSP on targets where the compiler doesn't support it at all
(mips, alpha) or it's known broken (sh3). But enable FORTIFY_SOURCE,
without SSP, on those platforms -- tested on mipsel.
(what other systems keep in libssp, we already have in libc) into libc
to match what other systems with FORTIFY_SOURCE do. Goodbye, libssp
dependency in libraries and executables. Discussed with christos and
mrg; Christos will merge the headers to get us the rest of the way to a
FORTIFY_SOURCE implementation that works as others' code expects.
FORTIFY_SOURCE feature of libssp, thus checking the size of arguments to
various string and memory copy and set functions (as well as a few system
calls and other miscellany) where known at function entry. RedHat has
evidently built all "core system packages" with this option for some time.
This option should be used at the top of Makefiles (or Makefile.inc where
this is used for subdirectories) but after any setting of LIB.
This is only useful for userland code, and cannot be used in libc or in
any code which includes the libc internals, because it overrides certain
libc functions with macros. Some effort has been made to make USE_FORT=yes
work correctly for a full-system build by having the bsd.sys.mk logic
disable the feature where it should not be used (libc, libssp iteself,
the kernel) but no attempt has been made to build the entire system with
USE_FORT and doing so will doubtless expose numerous bugs and misfeatures.
Adjust the system build so that all programs and libraries that are setuid,
directly handle network data (including serial comm data), perform
authentication, or appear likely to have (or have a history of having)
data-driven bugs (e.g. file(1)) are built with USE_FORT=yes by default,
with the exception of libc, which cannot use USE_FORT and thus uses
only USE_SSP by default. Tested on i386 with no ill results; USE_FORT=no
per-directory or in a system build will disable if desired.
lukem