r307825 and r333017 disallow building FreeBSD-HEAD from 9.x or 10.x
versions that have some clang issues. The minimum supported Subversion
revisions and osreldates containing the fix are:
Version Min Rev osreldate
9.x r286035 903509
10.x r286033 1002501
9.3 is the final 9.x release and does not contain the r286035 fix.
10.3 is the first 10.x release with the fix. Thus, in practice 10.3 is
the oldest release that can build HEAD.
Although it may still be possible to build HEAD from an up-to-date
stable/9 it's not worth maintaining the special case when the branch
itself is unsupported and there are no usable releases from that branch.
Old UPDATING entries can be removed and the Clang warning in UPDATING
may be updated, in a future commit.
Approved by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15209
r318957 added special handling for stale ptrace dependency files to
support a -DNO_CLEAN build in a tree last built before r305012. That
revision is now over a year and a half old, so retire the special case.
Sponsored by: The FreeBSD Foundation
So that -DNO_CLEAN builds work.
This should be reverted after a sufficient transition period (perhaps 3
or 6 months).
Sponsored by: The FreeBSD Foundation
kernel.ucl uses a hardcoded boot/kernel for kldxref, which is the incorrect
directory when we're installing extra kernels that aren't the "default"
kernel (placed at boot/kernel).
Fix this by instead using a new %KERNELDIR% that we now replace in
Makefile.inc1 with "kernel" for the default kernel and "kernel.${_kernel}"
for these extra kernels so that, e.g. /boot/kernel.SHIVA, will get properly
kldxref'd upon update and avoid outdated linker.hints.
Reviewed by: gjb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14689
This allows working with custom cross toolchains without the need to
create files in /usr/local/share/toolchains.
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D14178
This code, which is basically `svnversion || svnliteversion`, generates
2 fstatat(2) for every directory in PATH for every Makefile parsed that
includes bsd.own.mk. This can add up for things like generating a Ports
index (Poudriere) or building a dependency graph for base.
Sponsored by: Dell EMC
MFC after: 2 weeks
bsd.compiler.mk. It's so fmake from older 9.x systems still
works (still a supported build config, and having the note here
will let us know when we can cull it more easily).
Also pull in a related change from include to sinclude from
arichardson@'s cross building work, as well as it's companion in
Makefile.inc1 with a note about why we do the odd thing there.
Submitted by: archardson
Differential Revision: https://reviews.freebsd.org/D14241
These features indicate that the compiler and linker support the
retpoline speculative execution vulnerability (CVE-2017-5715)
mitigation.
Reviewed by: dim, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14228
It won't work e.g. when crossbuilding from Ubuntu Linux as mktemp is in
/bin there.
Reviewed By: bdrewery
Approved By: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D13937
This fixes building libllvmminimal with MK_LLD support when WITHOUT_LLD
or WITHOUT_TOOLCHAIN are set, which are install flags not build tools
flags.
Reported by: sbruno
Tested by: sbruno
Sponsored by: Dell EMC
A comment in Makefile.inc1 has long stated that LOCAL_DIRS are built last,
after the base system. Incremental improvements in parallel building over
the years have led to LOCAL_DIRS being built in parallel with base system
directories. This change allows the .WAIT directive to appear in LOCAL_DIRS
and LOCAL_LIB_DIRS lists to give the user some control over parallel
building of local additions.
Differential Revision: https://reviews.freebsd.org/D13622
Because we force enable MK_GCC when building we need to also force
enable it for the cleaning phase. Otherwise the NXB_TARGET files
are found in the next build's kernel-toolchain phase and cause
an error.
Reported by: sbruno
X-MFC-With: r325001
MFC after: 1 month
Sponsored by: Dell EMC
The initial kernel-toolchain is built with TARGET=MACHINE but
we want GCC to have files generated for TARGET=NXB_TARGET
instead later on. Just clean the files between building of
the toolchain and nxb binaries which will let it rebuild
when needed.
Reported by: sbruno
X-MFC-With: r325001
MFC after: 1 month
Sponsored by: Dell EMC
Packaged base packages are created by running the stageworld and
stagekernel targets with -DNO_ROOT, and converting the resulting mtree
file into a set of pkg plists. If stage* is run with multiple processes
the order of entries in the mtree file may be nondeterministic, and the
resulting package tbz also had nondeterministic file ordering.
The mtree file generated by -DNO_ROOT builds consists of one line per
file, with the filename starting in the first column, so is easily
sorted. There's one exception: the first line of the mtree file is a
comment, but the # character sorts before the filenames anyhow and needs
no special treatment.
PR: 223673
Reviewed by: bapt, gjb
Sponsored by: The Linux Foundation, Core Infrastructure Initiative
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13103
Before this patch libmagic was always built in the build-tools phase
even if -DWITHOUT_FILE was specified.
Reviewed by: emaste, jhb
Approved by: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D12925
- This also adds in a _cleanobj step as needed.
- This redirects TARGET/TARGET_ARCH to NXB_TARGET/NXB_TARGET_ARCH in
Makefile.inc1 as the main build needs to be for MACHINE rather
than TARGET.
First build the toolchain and then use that as an external toolchain
to build the needed directories and NXB_TARGET-toolchain, all as
MACHINE files though via TARGET_TRIPLE=MACHINE_TRIPLE.
The NXBDIRS is evaluated in the 'everything' submake as it needs to be
based on TARGET's src.opts.mk values, such as MK_GCC=yes when building
on a MK_CLANG=yes MACHINE. This can likely be changed to a specific
_native-xtools-everything target later and the funky late evaluation
of SUBDIR_OVERRIDE removed.
X-MFC-With: r325001
Pointyhat to: bdrewery
MFC after: 2 months
Sponsored by: Dell EMC Isilon
- If OBJROOT is SRCTOP then don't add on TARGET.TARGET_ARCH. This
only happens at the top-level, and for sub-directories when the
user is clever with MAKEOBJDIRPREFIX=/.
- Don't bother checking 'test -w' on .CURDIR.
- Properly set OBJTOP/OBJROOT to SRCTOP in various needed cases.
- Check if the OBJDIR is writable even for *clean* targets since it
determines which .OBJDIR the user gets; If they cannot write to an
existing eligible .OBJDIR then it needs to clean in .CURDIR instead.
- Add guard to cleanworld/cleanuniverse from removing SRCTOP.
- Ensure OBJTOP is proper for .OBJDIR=.CURDIR which fixes finding
libraries since src.libnames.mk is based on OBJTOP.
- Avoid some chdir(2) for modifying .OBJDIR
Sponsored by: Dell EMC Isilon
This problem was caused by r325329 and r325350.
For the release(7) targets, some will run mm-mtree.sh which itself runs make
with a MAKEOBJDIRPREFIX. The execution of that script leaks OBJROOT,
MAKEOBJDIR, and MAKELEVEL=1 in the environment. This causes the mm-mtree makes
to not do some basic setup of OBJROOT and only use this special
MAKEOBJDIRPREFIX case which fails to empty out MAKEOBJDIRPREFIX for further
nested makes, such as a tree walk. If that tree walk sets OBJROOT/OBJTOP such
as r325329 is doing, then the wrong OBJDIRs end up being used due to the
unemptied MAKEOBJDIRPREFIX being preferred over the proper MAKEOBJDIR.
Pointyhat to: bdrewery
Sponsored by: Dell EMC Isilon
NO_OBJ has a very specific meaning in sub-directories in that no object
directory will be made. If a user wanted to skip the 'make obj' phase then
passing -DNO_OBJ would break all sub-directories from building properly. Using
NO_OBJ internally also causes issue with NO_OBJ handling being added in
share/mk/bsd.init.mk soon.
Sponsored by: Dell EMC Isilon
This still keeps the reduced MAKEOBJDIRPREFIX (SRCTOP) redundancy
removed in the OBJDIR, but now keeps all early phase objects
in the same directory rather than split per phase.
The problem of splitting per phase is that later phases want to link in
libraries from earlier phases and base their location on ${OBJTOP}.
Pointyhat to: bdrewery
Reported by: mjoras, Mark Millard
Sponsored by: Dell EMC Isilon
This will force any existing objects to rebuild if their .meta
files reference files from WORLDTMP. This is a problem after
the UNIFIED_OBJDIR effort caused buildworld and DIRDEPS_BUILD
to share an OBJDIR. Without cleaning these files the
Makefile.depend files end up with odd tmp/legacy/... entries
since some bootstrap-tools linger from there and otherwise
don't rebuild. Removing the files causes anything having
used WORLDTMP to rebuild.
Sponsored by: Dell EMC Isilon
Given MACHINE/MACHINE_ARCH=amd64, TARGET=arm64 and TARGET_ARCH=aarch64,
this change will build them in a location such as:
/usr/obj/usr/src/amd64.amd64/nxb/arm64.aarch64/
and
/usr/obj/usr/src/amd64.amd64/xdev/aarch64-freebsd/
Sponsored by: Dell EMC Isilon
