The condition used matches the condition in sys.mk for setting _+_ to blank
or +.
With this -n will continue to not descend into Makefile.inc1, while -n -n will
and cause Makefile.inc1's target to run with -n.
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
This is relevant for makeman using the 'make targets' output in src.conf(5).
This makes a _UNIVERSE_TARGETS that removes arm64 if the build
requirements are not met.
bmake specific constructs not needed for make bootstrap so fmake
doesn't see them. This works with fmake just well enough for us to
build bmake to build the rest of the tree without fatal errors. Tested
only with fmake package.
arm64 relies on an external binutils port or package right now, because
the in-tree linker from binutils 2.17.50 does not support arm64. Add
arm64 to universe if the linker is available. If not output a message
that arm64 is skipped.
buildworld and buildkernel use the external binutils automatically, so
it's sufficient to run 'pkg install aarch64-binutils' to build
FreeBSD/arm64.
Differential Revision: https://reviews.freebsd.org/D2302
Reviewed by: andrew, imp
Sponsored by: The FreeBSD Foundation
only adds support for kernel-toolchain, however it is expected further
changes to add kernel and userland support will be committed as they are
reviewed.
As our copy of binutils is too old the devel/aarch64-binutils port needs
to be installed to pull in a linker.
To build either TARGET needs to be set to arm64, or TARGET_ARCH set to
aarch64. The latter is set so uname -p will return aarch64 as existing
third party software expects this.
Differential Revision: https://reviews.freebsd.org/D2005
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
building toolchain for the host computer. This toolchain produces
TARGET_ARCH and assumes the rest of the system contains libraries for
the target. It is intended to be used in a "qemu-user jail" where all
the binaries would otherwise be the target architecture's to build
ports. However, emulation of the compilers is too slow, so we build
native binaries for that. Rather than use the xdev produced binaries,
with all their weird links and paths, these binaries use the native
paths. They will not work unless installed into the qemu-user jail.
Differential Revision: https://phabric.freebsd.org/D518
Reviewed by: sbruno@
During "make buildworld", building bmake is (one of) the very first steps
and we should not be building any of its tests. Conceptually, this is the
right thing to do 1) for build simplicity reasons and 2) because there is
no need to build any tests this early on.
In practice, this fixes tinderbox builds of CURRENT from 9.x when MK_TESTS
is enabled. This is because bsd.test.mk needs some modern bmake features
not present in 9.x (:tW) and tinderbox is forcing the build to use the
CURRENT share/mk files from the very beginning (see r266617). By skipping
the build of the tests when still using the host make, we omit the problem.
Arguably, what tinderbox is doing is wrong and needs to be addressed, but
that is a separate issue.
UPDATING. This is the first step towards the removal of ia64 from
head. A buildworld for ia64 will now yield:
% make buildworld
make[1]: "/usr/src/Makefile.inc1" line 151: Unknown target ia64:ia64.
While here, trim the ia64-specific additions from ObsoleteFiles.inc
Discussed at: BSDcan
in them. This is often the case, so just ignore the return
code. Actual errors that are found will also be detected downstream in
the rare cases where the return code is 2 instead of 1.
environments (that I can't reproduce locally, but that others have
reported) seem to get tripped up by this man page install. There's
really no need to do it, so turn off the man pages using the most
portable method. We can't just directly set MK_MAN=no here because
we're bootstrapping in the host environment and such a setting was
forbidden until very recently. NO_MAN= can produce a warning, but for
now the warning is benign.
build world, so it is the only make we build or install. fmake is
still in the tree, but disconnected, and upgrades from older systems
that still have bmake has not been removed, but its state has not been
tested (it should work given how minimal the work to upgrade to bmake
is).
#NO_UNIVERSE. Many of these config files are important examples, but
add little to no regresive value to the intended purpose of
UNIVERSE. We now build over 120 kernels during universe. There's
really little to no value to this over building say 60 or even 30 of
them (either is still a way too big number). This is especially true
for kernels that are nothing more than including a common base and
adding a static DTB file. Start by pruning 1/3 of the arm kernels that
add little regresion value.
commit 1d1b908107255ffdff4d17f015d8f057d73cc6cb
Author: Brooks Davis <brooks@one-eyed-alien.net>
Date: Fri Mar 28 16:24:45 2014 +0000
Add a long needed seatbelt.
Exit with an error when make is called without a target at the top level
rather than poluting the source tree and causing use confusion in future
builds.
commit a9d9aa341b2f4308a227ab460ba85f1f287ad028
Author: Brooks Davis <brooks@one-eyed-alien.net>
Date: Tue Apr 29 16:06:12 2014 +0000
Simplify seatbelt added in 1d1b908 based in feedback.
Discussed with: imp@FreeBSD.org
Reviewed by: imp
Sponsored by: DARPA, AFRL
This targets the existing ARMv6 and ARMv7 SoCs that contain a VFP unit.
This is an optional coprocessors may not be present in all devices, however
it appears to be in all current SoCs we support.
armv6hf targets the VFP variant of the ARM EABI and our copy of gcc is too
old to support this. Because of this there are a number of WITH/WITHOUT
options that are unsupported and must be left as the default value. The
options and their required value are:
* WITH_ARM_EABI
* WITHOUT_GCC
* WITHOUT_GNUCXX
In addition, without an external toolchain, the following need to be left
as their default:
* WITH_CLANG
* WITH_CLANG_IS_CC
As there is a different method of passing float and double values to
functions the ABI is incompatible with existing armv6 binaries. To use
this a full rebuild of world is required. Because no floating point values
are passed into the kernel an armv6 kernel with VFP enabled will work with
an armv6hf userland and vice versa.
broken. None of our kernels can boot armv6eb. The little-endian kernels do
not have the required code to be able to switch endian when running a
big-endian executable.
Approved by: re (gjb)
