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
This changes the build OBJDIR from the older style of /usr/obj/<srcdir> for
native builds, and /usr/obj/<target>.<target_arch>/<srcdir> for cross builds to
a new simpler format of /usr/obj/<srcdir>/<target>.<target_arch>. This
new format is used regardless of cross or native build. It allows
easier management of multiple source tree object directories.
The UNIFIED_OBJDIR option will be removed and its feature made permanent
for the 12.0 release.
Relnotes: yes (don't note UNIFIED_OBJDIR option since it will be removed)
Prior work: D3711 D874
Reviewed by: gjb, sjg
Discussed at: https://lists.freebsd.org/pipermail/freebsd-arch/2016-May/017805.html
Discussed with: emaste
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12840
Due to removing some targets that the previous .ORDER: ${WMAKE_TGTS}
set, it was no longer being respected; _build_tools was coming
immediately.
Pointyhat to: bdrewery
X-MFC-with: r325244
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
There's no good reason to treewalk the entire tree removing old OBJDIRS
and creating new ones when 'includes', 'libraries', and 'everything' are
all skipped. The only shared directory in the existing toolchain target
and world is build-tools. So handle cleaning in it directly if needed
only for the directories it wants to build.
The extra _obj/_cleanobj walks came in the initial kernel-toolchain
addition in r128189.
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
It merely wanted to use 'all' rather than 'build-tools' so just
add a build-tools target to the Makefile.
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Now that a proper sysroot is used and a separate target list, it should
be safe to skip building the initial cross-compiler.
X-MFC-With: r325001
MFC after: 1 month
Sponsored by: Dell EMC Isilon
make buildenv BUILDENV_SHELL=<some command> more useful. Remove '||
true' from the command line so that errors are properly
returned. There appears to be no reason for it, and it dates back to
the original commit by ru@.
Sponsored by: Netflix
It is possible that building headers requires an OBJDIR.
The other phases of xdev have their own 'make obj' calls
where needed, such as inside 'make libraries' itself.
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Without this the user has to mess with 'make -f Makefile.inc1 ...' to figure
out where the files are installed in the OBJDIR and then they need to copy them
to where they really wanted them. Using DESTDIR may be problematic after
r325001 as well.
The files will be installed to DESTDIR/NXTP where NXTP defaults to /nxb-bin.
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
The top of Makefile.inc1 requires TARGET/TARGET_ARCH be defined. Just
building 'make xdev' would already set them, so this error was never
triggered. Moving it to Makefile fixes the problem.
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Its own build target was already handling mtree extractions
just as _worldtmp did, so the other cleaning of the
tmpdir makes sense here as well.
Sponsored by: Dell EMC Isilon
Only remove them if the option is enabled and also handle libsoft
by using the proper LIBCOMPAT_OBJTREE. LIBCOMPAT:D will expand
the text after it as a proper glob to the command line if LIBCOMPAT
is defined.
Sponsored by: Dell EMC Isilon
The _worldtmp target is for setting up WORLDTMP. Nothing between _worldtmp
and _cleanobj will read these files. Move to its own target since it is
so large.
Sponsored by: Dell EMC Isilon
This leaks into the PATH handling for WORLDTMP and breaks
finding cross-tools. The PATH handling could be fixed to
properly quote but is not worth the effort.
Also allow this sanity check to always run even with 'make -n'.
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
This takes longer but should reliably produce working binaries.
The old version linked against system libraries and headers
which would be a problem if building a native-xtools against
a newer source than the host system. With a proper sysroot made
first this is not a problem.
This also allows:
- NXBDIRS to be built in parallel
- NXBDIRS to be installed to NXBDESTDIR in parallel
- SYSTEM_COMPILER logic to work again. Note that because this change
is adding a sysroot phase the compiler may be built up to twice now.
The first is the "cross-compiler" even though it is for the native
architecture, but it is still built to ensure the latest compiler
is used to generate the binaries, unless SYSTEM_COMPILER allows
/usr/bin/cc to be used. Then the target compiler is built
which is actually a cross-compiler since it runs on native host
but generates TARGET.TARGET_ARCH binaries.
Note this also changes the path used for the OBJDIR. It used to use
/usr/obj/target.target_arch/nxb/<srcdir> for objects and
/usr/obj/target.target_arch/nxb-bin for installed files, but now uses
/usr/obj/nxb/target.target_arch/<srcdir> for objects and
/usr/obj/nxb/target.target_arch/<srcdir>/nxb-bin for installed files.
- NXBDESTDIR can be specified for where to install or queried with
`make -f Makefile.inc1 TARGET=... TARGET_ARCH=... -V NXBDESTDIR`
This could potentially be improved to reuse an existing sysroot. The
problem is with building the SUBDIR_OVERRIDE list it needs to use a
different OBJDIR since it is building all statically. We don't want to
pollute the existing 'buildworld' OBJDIR and cause confusion on the next
build. Using a separate OBJDIR for the 'everything' phase mostly works
except for some things like linking in INTERNALLIBS that exist in the
other OBJDIR.
MFC after: 1 month
Sponsored by: Dell EMC Isilon
Make armv7 as a new MACHINE_ARCH.
Copy all the places we do armv6 and add armv7 as basically an
alias. clang appears to generate code for armv7 by default. armv7 hard
float isn't supported by the the in-tree gcc, so it hasn't been
updated to have a new default.
Support armv7 as a new valid MACHINE_ARCH (and by extension
TARGET_ARCH).
Add armv7 to the universe build.
Differential Revision: https://reviews.freebsd.org/D12010
files will produce an error and buildkernel will fail. Previously missing
KERNCONF files silently failed giving no indication as to why, only to
subsequently discover during installkernel that the desired kernel was
never built in the first place.
This is a rework of r302865.
This is the correct patch.
Reviewed by: ngie (previous version, r302865)
MFC after: 2 months
Differential Revision: D7167
files will produce an error and buildkernel will fail. Previously missing
KERNCONF files silently failed giving no indication as to why, only to
subsequently discover during installkernel that the desired kernel was
never built in the first place.
This is a rework of r302865.
Reviewed by: ngie (previous version, r302865)
MFC after: 2 months
Differential Revision: D7167
This causes builds to use the in-tree libdwarf with the bug fix instead
of the host library.
Reviewed by: bdrewery, emaste, markj
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12239
This helps reduce the WORLDTMP footprint slightly.
Based on a patch I submitted 5 years ago to GNATS.
PR: 174051
MFC after: 2 weeks
Relnotes: yes (anyone who cross-builds with MK_TCSH=yes will run into
build failures if the host doesn't have tcsh(1))
Reminded by: Fabian Keil <fk@fabiankeil.de>
LLD_BOOTSTRAP is intended to control the linker used to link world and
kernel, while LLD_IS_LD is intended to control the linker installed in
that world.
Force LLD_IS_LD equal to LLD_BOOTSTRAP for the cross-tools build and
install phase, so that lld will be installed as the ld to run on the
host, when LLD_BOOTSTRAP is set.
PR: 221543
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D12072
Disconnect the dependency on the kernel package from the runtime
package. There are a number of problems here:
1) The runtime package installed into a chroot or a jail would
include the kernel package, changing the behavior of how jails
work now [1];
2) As result of (1), it is possible a binary may incorrectly
resolve kernel symbols [2]; in addition, it is possible there
will be unexpected fallout with 32-bit jails on a 64-bit host
kernel [2].
Noticed by: brd [1]
Discussed with: kib [2]
MFC after: 3 days
MFC note: record-only to wipe from the merge tracker
Sponsored by: The FreeBSD Foundation
svnversion metadata to the runtime and kernel packages.
Instead of traversing src/sys, as is done by newvers.sh for uname(1),
a full tree walk is done to prevent userland and/or modifications
from not being reflected in a modified tree (M).
MFC after: 5 days
Sponsored by: The FreeBSD Foundation
The idea here is that, provided upstream pkg(8) maintainers accept
the proposed change, the kernel.ucl will contain a post-install
script causing pkg(8) to emit a message informing to reboot the
system after the kernel is upgraded using 'pkg upgrade', so the
new userland is installed on the running new kernel. At present,
this functionality does not exist in pkg(8), but will help ensure
the upgrade path follows that from UPDATING. To work around this
for now, evaluate ASSUME_ALWAYS_YES, and prompt the user if they
wish to proceed if not set to true.
Since there is a kernel dependency, and a non-GENERIC kernel may
be in use, update Makefile.inc1 to replace '%KERNCONF%' in the
runtime.ucl with the first-built kernel set either via command line
or in make.conf(5).
MFC after: 5 days
Sponsored by: The FreeBSD Foundation
arches), and handle two more cases where libc++ includes could be
incorrectly enabled, in case the host compiler is clang 5.0.0, and the
target (cross) compiler is gcc 4.2.1.
Noted by: bdrewery
MFC after: 3 days
X-MFC-With: 321684
- bsd.compiler.mk: Must ensure that the CCACHE_WRAPPER_PATH comes first
in PATH.
- Makefile.inc1: Must prepend the CCACHE_WRAPPER_PATH into BPATH as it
overrides the PATH set in bsd.compiler.mk in sub-makes. The PATH
set in bsd.compiler.mk is not exported and doing so would cause it to
then override the BPATH set from environment. The only sane solution
is to prepend into BPATH as needed.
CCACHE_PATH could possibly be used for some of this as well.
Sponsored by: Dell EMC Isilon
Since we imported clang 5.0.0, the version check in Makefile.inc1 which
checks whether to use libc++ fires even when the compiler for the target
architecture is gcc 4.2.1. This is because only X_COMPILER_VERSION is
checked. Also check X_COMPILER_TYPE, so it will only use libc++ when an
external gcc toolchain is used.
Reviewed by: emaste, rpokala
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D11776
It is full of distracting noise about UPDATING and may confuse
the user about what is actually being deleted. It is also
possible to have directories removed on every run with
use of WITHOUT_ knobs that the mtree files do not
account for and for which the directories are incorrectly
in OLD_DIRS currently.
X-MFC-With: r321443
MFC after: 1 month
Sponsored by: Dell EMC Isilon
This dependency does nothing since cddl/lib/libzfs is never
added into the 'make libraries' dependency chain
directly.
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
This prevents situations with -DNO_CLEAN from finding stale headers or
libraries in places that no longer exist or have moved. It avoids
the need to remove all of WORLDTMP by reusing what we already know
is obsolete.
MFC after: 1 month
Sponsored by: Dell EMC Isilon
The files are only ever generated to .OBJDIR, not to WORLDTMP (as a
sysroot) and are only ever included from a compilation. So using
a beforebuild target here removes the file before the compilation
tries to include it.
MFC after: 2 months
X-MFC-With: r321369
clang 4.0.0. Otherwise, these can get included before the two newly
generated ones (which are different) for clang 5.0.0.
Reported by: Mark Millard
MFC after: 2 months
X-MFC-With: r321369
