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
In a scenario of cross-building it is possible that an OBJDIR's WORLDTMP
contains an older compiler in WORLDTMP/usr/bin/cc that is not rebuilt
if SYSTEM_COMPILER logic is triggered. This compiler was still
incorrectly used. Address this by removing WORLDTMP/usr/bin/cc and all
of the hardlinked files associated with it. Also do this for c++ for
GCC builds.
Sponsored by: Dell EMC Isilon
MFC after: 1 week
Our current approach to dependency tracking cannot cope with switching
generated asm syscall stubs into C wrappers. Perpetuate the hack in
Makefile.inc1 to paper over the problem until we can take a holistic
approach to fixing dependency problems.
Differential Revision: https://reviews.freebsd.org/D11344
