freebsd-dev/stand/Makefile.inc


SUBDIR_PARALLEL=	yes

.include "defs.mk"
Enable GCC stack protection (aka Propolice) for userland: - It is opt-out for now so as to give it maximum testing, but it may be turned opt-in for stable branches depending on the consensus. You can turn it off with WITHOUT_SSP. - WITHOUT_SSP was previously used to disable the build of GNU libssp. It is harmless to steal the knob as SSP symbols have been provided by libc for a long time, GNU libssp should not have been much used. - SSP is disabled in a few corners such as system bootstrap programs (sys/boot), process bootstrap code (rtld, csu) and SSP symbols themselves. - It should be safe to use -fstack-protector-all to build world, however libc will be automatically downgraded to -fstack-protector because it breaks rtld otherwise. - This option is unavailable on ia64. Enable GCC stack protection (aka Propolice) for kernel: - It is opt-out for now so as to give it maximum testing. - Do not compile your kernel with -fstack-protector-all, it won't work. Submitted by: Jeremie Le Hen <jeremie@le-hen.org> 2008-06-25 21:33:28 +00:00
stand: properly declare subdir deps or .WAIT, do parallel build buildworld already runs the stand build in parallel[1], so make it easier to identify ordering issues by properly establishing dependencies or adding .WAIT where needed. Everything in stand/ relies on libsa, either directly or indirectly, because libsa build is where the stand headers get installed and it gets linked in most places. Interpreters depend on their libs, machine dirs usually depend on top-level libs that are getting built and at least one of the interpreter flavors. For i386, order btx/libi386/libfirewire before everything else using a big-ol-.WAIT hammer. btx is the most common dependency, but the others are used sporadically. This seems to be where the race reporting on the mailing list is- AFAICT, the following sequence is happening: 1.) One of the loaders gets built based on stale btx/btxldr 2.) btx/btxldr gets rebuilt 3.) installworld triggers loader rebuild because btx was rebuilt after This seems like the most plausible explanation, as they've verified system time and timestamps. While we're here, let's switch stand/ over to a completely parallel build so we can work out these kinds of issues in isolation rather than in the middle of a larger build. Reviewed by: bdragon, sjg, tsoome Tested by: bdragon (-j1024, no failures, significant speed improvement) Differential Revision: https://reviews.freebsd.org/D23411 2020-12-31 17:15:45 +00:00			`SUBDIR_PARALLEL= yes`

create defs.mk for common definitions 2017-10-16 03:59:38 +00:00			`.include "defs.mk"`