r288829 states that lex requires the latest m4, but was not always building it.
Move lex to the same logic as m4 since they are closely tied now.
MFC after: 3 days
Sponsored by: EMC / Isilon Storage Division
Reported by: Slawa Olhovchenkov <slw@zxy.spb.ru>
- Rework MANIFEST generation and parsing via bsdinstall(8).
- Allow selecting debugging distribution sets during install.
- Rework bsdinstall(8) to fetch remote debug distribution sets
when they are not available on the local install medium.
- Allow selecting additional non-GENERIC kernels during install.
At present, GENERIC is still required, and installed by default.
Tested with: head@r293203
Sponsored by: The FreeBSD Foundation
not set. The 'stageworld' target is invoked with -DNO_ROOT, so the
metalog file(s) will be created regardless.
This matches the behavior of 'create-world-packages'.
Sponsored by: The FreeBSD Foundation
This retains the original behavior of release-related targets, which
assume 'buildworld' and 'buildkernel' have already happened.
Sponsored by: The FreeBSD Foundation
Instead of using which(1) to look for doxygen, look for it in <LOCALBASE>/bin .
$PATH gets mangled by make buildenv, etc so it's better to just be explicit
about the path if someone uses that for instance.
Differential Revision: https://reviews.freebsd.org/D4406 (part of a larger diff)
Reviewed by: emaste, Evan Cramer <eccramer@gmail.com>
Sponsored by: EMC / Isilon Storage Division
It does not properly import PATH; the PATH is reset by included profile
files on startup which breaks the biggest feature of buildenv (using
sysrooted cc from WORLDTMP)
Spotted by: smh, kib
Sponsored by: EMC / Isilon Storage Division
RISC-V is a new ISA designed to support computer research and education, and
is now become a standard open architecture for industry implementations.
This is a minimal set of changes required to run 'make kernel-toolchain'
using external (GNU) toolchain.
The FreeBSD/RISC-V project home: https://wiki.freebsd.org/riscv.
Reviewed by: andrew, bdrewery, emaste, imp
Sponsored by: DARPA, AFRL
Sponsored by: HEIF5
Differential Revision: https://reviews.freebsd.org/D4445
- Don't bother looking up REVISION/BRANCH/etc from release/, or the
CPUTYPE check, as these are not used for makeman and wastes time. The also
invokes auto.obj.mk after I reverted auto.obj.mk ignoring -V in r291312.
- Don't modify CC or PATH when WITH_CCACHE_BUILD or WITH_META_MODE is enabled
as it leads to bsd.compiler.mk errors.
Sponsored by: EMC / Isilon Storage Division
This is to fix 'make all' causing it to recurse on both 'all' and 'buildconfig'
due to 'buildconfig' being in ALL_SUBDIR_TARGETS and being a dependency of
'all'.
This now adds all of the '*includes', '*files' targets as subdir targets,
allowing them to recurse.
This also removes the need for some 'realinstall' hacks in bsd.subdir.mk since
it no longer recurses; only 'install' will recurse and call the proper
'beforeinstall', 'realinstall', and 'afterinstall' in each sub-directory.
This fixes 'make includes' and 'make files' to not be a rerolled ${MAKE}
sub-shell but to rather just recurse on 'inclues' and 'files'. This avoids
various issues such as the one fixed in r289462. As such revert Makefile.inc1
back to using 'includes' which avoids an extra tree walk and parallelizes
the includes phases better.
Makefile.inc1 includes a guard so that 'make all' will not use SUBDIR_PARALLEL,
added in r289438. This is so users do not get a probably broken build if they
run 'make all' from the top-level. Before the change in this commit, the
workaround for 'make everything' was 'par-all' which would depend on 'all' and
cause a proper parallel recursion. Now that will not work so a new
_PARALLEL_SUBUDIR_OK is used to allow it.
This is still part of an effort to combine bsd.(files|incs|confs).mk and move
some of its logic out of bsd.subdir.mk, as attempted in r289282 and reverted in
r289331. This commit fixes the problems found there which was mostly double
recursing during 'includes' which would recurse on itself and 'buildincludes'
and 'installincludes', all in parallel. The logic is still in bsd.subdir.mk
for now.
I've been cautious about this commit but have experienced no breakage on the
tree except for the 'par-all' case which was already a hack. If something foo
is depending on something bar that should recurse, it is very likely that the
foo target is being recursed on already meaning that bar will still effectively
recurse once sub-directories call foo.
Discussed on: arch@
MFC after: never
Sponsored by: EMC / Isilon Storage Division
installed as "kernel". This is relevant for packaging of the kernel when
not wanting a default "kernel.txz".
Submitted by: Russell Cattelan <cattelan@thebarn.com>
MFC after: 2 weeks
Obtained from: OneFS
Sponsored by: EMC / Isilon Storage Division
Say it with me, "I will not chain commands with && in Makefiles"
This was originally fixed and explained quite well by bde@ in r36074. The
initial bmake integration caused 'set -e' to stop being used which lead to
r252419. Later 'set -e' expectations were fixed with bmake in r254980.
Because of the && here, errors would be ignored when building in parallel and
a dependency failed. Such as bootstrap-tools since it builds everything in
parallel. If any tool failed in obj/depend/all, it would just ignore the error
and continue to build. This later would result in cascaded errors that only
confused the real issue. This could also cause commands after the failed
command to still execute, leading to more confusion.
This should be fine if the command is in a sub-shell such as: (cmd1 && cmd2)
This reverts r252419.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
- Add a kvaddr_type to represent kernel virtual addresses instead of
unsigned long.
- Add a struct kvm_nlist which is a stripped down version of struct nlist
that uses kvaddr_t for n_value.
- Add a kvm_native() routine that returns true if an open kvm descriptor
is for a native kernel and memory image.
- Add a kvm_open2() function similar to kvm_openfiles(). It drops the
unused 'swapfile' argument and adds a new function pointer argument for
a symbol resolving function. Native kernels still use _fdnlist() from
libc to resolve symbols if a resolver function is not supplied, but cross
kernels require a resolver.
- Add a kvm_nlist2() function similar to kvm_nlist() except that it uses
struct kvm_nlist instead of struct nlist.
- Add a kvm_read2() function similar to kvm_read() except that it uses
kvaddr_t instead of unsigned long for the kernel virtual address.
- Add a new kvm_arch switch of routines needed by a vmcore backend.
Each backend is responsible for implementing kvm_read2() for a given
vmcore format.
- Use libelf to read headers from ELF kernels and cores (except for
powerpc cores).
- Add internal helper routines for the common page offset hash table used
by the minidump backends.
- Port all of the existing kvm backends to implement a kvm_arch switch and
to be cross-friendly by using private constants instead of ones that
vary by platform (e.g. PAGE_SIZE). Static assertions are present when
a given backend is compiled natively to ensure the private constants
match the real ones.
- Enable all of the existing vmcore backends on all platforms. This means
that libkvm on any platform should be able to perform KVA translation
and read data from a vmcore of any platform.
Tested on: amd64, i386, sparc64 (marius)
Differential Revision: https://reviews.freebsd.org/D3341
The bootstrap-tools are supposed to be host tools, which in most cases, use
host headers and libraries. As such, directly including the src tree's headers
for libmd here causes the need to link libmd in since it will be built with
the new symbols (which /usr/lib/libmd.so) won't have unless it is new enough.
During the target build in buildworld the target headers are staged into
WORLDTMP and used via --sysroot, allowing the target xinstall to be built with
the new/target libmd.
The .PATH here was also not doing anything since xinstall does not use libmd
source files.
Sponsored by: EMC / Isilon Storage Division
MFC after: 2 weeks
This simplifies the logic to always try removing the objdir if it exists
and to fallback on a 'cleandir' if no objdir exists. The reasoning for
this is to avoid rm -rf src/* (r126024)
Sponsored by: EMC / Isilon Storage Division
MFC after: 2 weeks
This leads the way for fixing cross-build cleanup, and eventually replacing
'cleandir' with it during the build.
Sponsored by: EMC / Isilon Storage Division
MFC after: 2 weeks
ccache is mostly beneficial for frequent builds where -DNO_CLEAN is not
used to achieve a safe pseudo-incremental build. This is explained in
more detail upstream [1] [2]. It incurs about a 20%-28% hit to populate the
cache, but with a full cache saves 30-50% in build times. When combined with
the WITH_FAST_DEPEND feature it saves up to 65% since ccache does cache the
resulting dependency file, which it does not do when using mkdep(1)/'CC
-E'. Stats are provided at the end of this message.
This removes the need to modify /etc/make.conf with the CC:= and CXX:=
lines which conflicted with external compiler support [3] (causing the
bootstrap compiler to not be built which lead to obscure failures [4]),
incorrectly invoked ccache in various stages, required CCACHE_CPP2 to avoid
Clang errors with parenthesis, and did not work with META_MODE.
The option name was picked to match the existing option in ports. This
feature is available for both in-src and out-of-src builds that use
/usr/share/mk.
Linking, assembly compiles, and pre-processing avoid using ccache since it is
only overhead. ccache does nothing special in these modes, although there is
no harm in calling it for them.
CCACHE_COMPILERCHECK is set to 'content' when using the in-tree bootstrap
compiler to hash the content of the compiler binary to determine if it
should be a cache miss. For external compilers the 'mtime' option is used
as it is more efficient and likely to be correct. Future work may optimize the
'content' check using the same checks as whether a bootstrap compiler is needed
to be built.
The CCACHE_CPP2 pessimization is currently default in our devel/ccache
port due to Clang requiring it. Clang's -Wparentheses-equality,
-Wtautological-compare, and -Wself-assign warnings do not mix well with
compiling already-pre-processed code that may have expanded macros that
trigger the warnings. GCC has so far not had this issue so it is allowed to
disable the CCACHE_CPP2 default in our port.
Sharing a cache between multiple checkouts, or systems, is explained in
the ccache manual. Sharing a cache over NFS would likely not be worth
it, but syncing cache directories between systems may be useful for an
organization. There is also a memcached backend available [5]. Due to using
an object directory outside of the source directory though you will need to
ensure that both are in the same prefix and all users use the same layout. A
possible working layout is as follows:
Source: /some/prefix/src1
Source: /some/prefix/src2
Source: /some/prefix/src3
Objdir: /some/prefix/obj
Environment: CCACHE_BASEDIR='${SRCTOP:H}' MAKEOBJDIRPREFIX='${SRCTOP:H}/obj'
This will use src*/../obj as the MAKEOBJDIRPREFIX and tells ccache to replace
all absolute paths to be relative. Using something like this is required due
to -I and -o flags containing both SRC and OBJDIR absolute paths that ccache
adds into its hash for the object without CCACHE_BASEDIR.
distcc can be hooked into by setting CCACHE_PREFIX=/usr/local/bin/distcc.
I have not personally tested this and assume it will not mix well with
using the bootstrap compiler.
The cache from buildworld can be reused in a subdir by first running
'make buildenv' (from r290424).
Note that the cache is currently different depending on whether -j is
used or not due to ccache enabling -fdiagnostics-color automatically if
stderr is a TTY, which bmake only does if not using -j.
The system I used for testing was:
WITNESS
Build options: -j20 WITH_LLDB=yes WITH_DEBUG_FILES=yes WITH_CCACHE_BUILD=yes
DISK: ZFS 3-way mirror with very slow disks using SSD l2arc/log.
The arc was fully populated with src tree files and ccache objects.
RAM: 76GiB
CPU: Intel(R) Xeon(R) CPU L5520 @2.27GHz
2 package(s) x 4 core(s) x 2 SMT threads = hw.ncpu=16
The WITH_FAST_DEPEND feature was used for comparison here as well to show
the dramatic time savings with a full cache.
buildworld:
x buildworld-before
+ buildworld-ccache-empty
* buildworld-ccache-full
% buildworld-ccache-full-fastdep
# buildworld-fastdep
+-------------------------------------------------------------------------------+
|% * # +|
|% * # +|
|% * # xxx +|
| |A |
| A|
| A |
|A |
| A |
+-------------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 3 3744.13 3794.31 3752.25 3763.5633 26.935139
+ 3 4519 4525.04 4520.73 4521.59 3.1104823
Difference at 95.0% confidence
758.027 +/- 43.4565
20.1412% +/- 1.15466%
(Student's t, pooled s = 19.1726)
* 3 1823.08 1827.2 1825.62 1825.3 2.0785572
Difference at 95.0% confidence
-1938.26 +/- 43.298
-51.5007% +/- 1.15045%
(Student's t, pooled s = 19.1026)
% 3 1266.96 1279.37 1270.47 1272.2667 6.3971113
Difference at 95.0% confidence
-2491.3 +/- 44.3704
-66.1952% +/- 1.17895%
(Student's t, pooled s = 19.5758)
# 3 3153.34 3155.16 3154.2 3154.2333 0.91045776
Difference at 95.0% confidence
-609.33 +/- 43.1943
-16.1902% +/- 1.1477%
(Student's t, pooled s = 19.0569)
buildkernel:
x buildkernel-before
+ buildkernel-ccache-empty
* buildkernel-ccache-empty-fastdep
% buildkernel-ccache-full
# buildkernel-ccache-full-fastdep
@ buildkernel-fastdep
+-------------------------------------------------------------------------------+
|# @ % * |
|# @ % * x + |
|# @ % * xx ++|
| MA |
| MA|
| A |
| A |
|A |
| A |
+-------------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 3 571.57 573.94 571.79 572.43333 1.3094401
+ 3 727.97 731.91 728.06 729.31333 2.2492295
Difference at 95.0% confidence
156.88 +/- 4.17129
27.4058% +/- 0.728695%
(Student's t, pooled s = 1.84034)
* 3 527.1 528.29 528.08 527.82333 0.63516402
Difference at 95.0% confidence
-44.61 +/- 2.33254
-7.79305% +/- 0.407478%
(Student's t, pooled s = 1.02909)
% 3 400.4 401.05 400.62 400.69 0.3306055
Difference at 95.0% confidence
-171.743 +/- 2.16453
-30.0023% +/- 0.378128%
(Student's t, pooled s = 0.954969)
# 3 201.94 203.34 202.28 202.52 0.73020545
Difference at 95.0% confidence
-369.913 +/- 2.40293
-64.6212% +/- 0.419774%
(Student's t, pooled s = 1.06015)
@ 3 369.12 370.57 369.3 369.66333 0.79033748
Difference at 95.0% confidence
-202.77 +/- 2.45131
-35.4225% +/- 0.428227%
(Student's t, pooled s = 1.0815)
[1] https://ccache.samba.org/performance.html
[2] http://www.mail-archive.com/ccache@lists.samba.org/msg00576.html
[3] https://reviews.freebsd.org/D3484
[5] https://github.com/jrosdahl/ccache/pull/30
PR: 182944 [4]
MFC after: 3 weeks
Sponsored by: EMC / Isilon Storage Division
Relnotes: yes
ZSH considers CPUTYPE a magic variable that will be the output of 'uname -m'
even if already set in environment when starting up.
The CPUTYPE?= check in Makefile.inc1 and supporting overriding CPUTYPE
manually in the buildenv shell make automatic workarounds too tricky
here. ZSH should really respect variables set in the environment before
trashing them.
X-MFC-With: r290423
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
Also pass BUILDENV=1 into the sub-shell to allow modifying PS1 in .profile such
as:
if [ -n "${BUILDENV}" ]; then
PS1="(buildenv) ${PS1}"
fi
SHELL defaults to 'sh' in share/mk/sys.mk, but is typically passed down by
the shell invoking make as well. Rather than forcing all 'buildenv' users
to use plain /bin/sh, let them use their favorite shell.
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
Discussed with: imp
Move CROSS_TOOLS stuff to top of file (before bsd.compiler.mk) so that
decisions made by bsd.compiler.mk can properly affect the defaults in
src.opts.mk. Move that to after bsd.compiler.mk. Add a comment about
why we include bsd.compiler.mk here despite the fact that src.opts.mk
currently does too. Also remove bsd.arch.inc.mk that's been OBE.
Differential Revision: https://reviews.freebsd.org/D4087
libopenbsd is an internal library which
to bring in compatibility stuff from OpenBSD.
This will allow us to bring in more
OpenBSD utilities into the FreeBSD base system.
We similarly use libnetbsd for bringing in stuff from NetBSD.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D4078
CXXFLAGS to sub-makes.
The bad passing also causes bsd.dep.mk's logic to selectively pull only some
flags from C[XX]FLAGS to not apply which can be seen with '-L' being passed to
mkdep when using an external compiler.
Now it can be used to effectively "build in a subdir". It will use the
'cross-tools', 'libraries', and 'includes' phases of 'buildworld' to properly
setup a WORLDTMP to use. Then it will build 'everything' only in the
listed SUBDIR_OVERRIDE directories. It is still required to list custom
library directories in LOCAL_LIB_DIRS if SUBDIR_OVERRIDE is something
that contains libraries outside of the normal area (such as
SUBDIR_OVERRIDE=contrib/ofed needing LOCAL_LIB_DIRS=contrib/ofed/usr.lib)
Without these changes, SUBDIR_OVERRIDE with buildworld was broken or hit
obscure failures due to missing libraries, includes, or cross compiler.
SUBDIR_OVERRIDE with 'make <target that is not buildworld>' will continue to
work as it did before although its usefulness is questionable.
With a fully populated WORLDTMP, building with a SUBDIR_OVERRIDE with
-DNO_CLEAN only takes a few minutes to start building the target
directories. This is still much better than building unneeded things via
'everything' when testing small subset changes. A BUILDFAST or
SKIPWORLDTMP might make sense for this as well.
- Add in '_worldtmp' as we still need to create WORLDTMP as later targets,
such as '_libraries' and '_includes' use it. This probably was avoiding
calling '_worldtmp' to not remove WORLDTMP for debugging purposes, but
-DNO_CLEAN can be used for that.
- '_legacy' must be included since '_build-tools' uses -legacy.
The SUBDIR_OVERRIDE change came in r95509, while -legacy being part
of build-tools came in r113136.
- 'bootstrap-tools' is still skipped as this feature is not for
upgrades.
- Fix buildworld combined with SUBDIR_OVERRIDE not installing all includes.
The original change for SUBDIR_OVERRIDE in r95509 kept '_includes'
and '_libraries' as building everything possible as the SUBDIR_OVERRIDE
could need anything from them. However in r96462 the real 'includes'
target was changed from manual sub-makes to just recursing 'includes'
on SUBDIR, thus not all includes have been installed into WORLDTMP since then
when combined with 'buildworld'.
This is not done unless calling 'make buildworld' as it would be
unexpected to have it go into all directories when doing 'make
SUBDIR_OVERRIDE=mydir includes'.
- Also need to build the cross-compiler so it is used with --sysroot.
If this is burdensome then telling the build to use the local compiler
as an external compiler (thus using a proper --sysroot to WORLDTMP) is
possible by setting CC=/usr/bin/cc, CXX=/usr/bin/c++, etc.
- Don't build the lib32 distribution with SUBDIR_OVERRIDE in buildworld
since it won't contain anything related to SUBDIR_OVERRIDE. Testing
of the lib32 build can be done with 'make build32'.
- Document these changes in build.7
Sponsored by: EMC / Isilon Storage Division
MFC after: 2 weeks
Extend OptionalObsoleteFiles.inc to delete all lib32 files when MK_LIB32 is
set to no on a system that previously had lib32 libraries installed.
Also, to prevent "make delete-old-dirs" from always deleting lib32 directories
after an installworld, move the lib32 subtree to its own mtree file that only
gets applied when MK_LIB32=yes.
Test: Ran "make delete-old" and "make delete-old-libs" on a system that never
had MK_LIB32 enabled, and on a system where MK_LIB32 was enabled and later
disabled. Did this both on amd64 and powerpc64.
Test: Ran "make tinderbox" without errors.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D3923
This has been handled since r228158 made MK_CTF dependent on MK_CDDL
in share/mk/bsd.opts.mk.
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
The 'includes' target is currently a pseudo target in bsd.subdir.mk that
does 'cd ${.CURDIR} && ${MAKE} buildincludes && ${MAKE} installincludes',
versus all over targets that just recurse.
In Makefile.inc1 the older duplicated bsd.subdir.mk logic for calling
'includes' was being executed in each subdir directly, meaning 'cd lib && make
includes' became 'cd lib && make buildincludes && make installincludes'. Now
that the bsd.subdir.mk logic is used it is calling 'make buildincludes && make
installincludes' from the top-level which pulls in the PATH=<default path>
from /Makefile.
The sub-make logic for 'includes' in bsd.subdir.mk was attempted to be removed
in r289282 but turned out to be wrong. I have a working version now but
it is not yet ready for commit. So for now in Makefile.inc1 split out
'includes' to 'buildincludes' and 'installincludes' which will avoid the
problem.
MFC after: 2 weeks
X-MFC-With: r289438
Sponsored by: EMC / Isilon Storage Division
sub-makes.
Some of the world phases that used plain '${MAKE} -f Makefile.inc1' were not
passing this variable along which caused them to look it up again. By
using bmake's .export we can remove it from all of the other environment
lines.
Add a comment about the usage for VERSION for ctfmerge.
Sponsored by: EMC / Isilon Storage Division
We pass BOOTSTRAPPING=${OSRELDATE} to some of the sub-makes. Rather than
chase every ${MAKE} invokation, just export it as bmake lets us.
Sponsored by: EMC / Isilon Storage Division
Back in r30113, the 'par-*' targets were added to parallelize portions of
the build in a very similar fashion as the SUBDIR_PARALLEL feature used in
r263778. Calling a target without 'par-' (for 'parallel') resulted in the
standard bsd.subdir.mk handling without parallelization. Given we have
SUBDIR_PARALLEL now there is no reason to duplicate the handling here.
In build logs this will result in the ${dir}.${target}__D targets now showing
as the normal ${target}_subdir_${dir} targets.
I audited all of the uses of Makefile.inc1 and Makefile's targets that use
bsd.subdir.mk and found that all but 'all' and 'install' were fine to use
as always parallel.
- For 'install' (from installworld -j) the ordering of lib/ and libexec/
before the rest of the system (described in r289433), and etc/ being last
(described in r289435), is all that matters. So now a .WAIT is added in
the proper places when invoking any 'install*' target. A parallel
installworld does work and took 46% of the time a non-parallel
install would take on my system with -j15 to ZFS.
- For 'all' I left the default handling for this to not run in parallel. A
'par-all' target is still used by the 'everything' stage of buildworld
to continue building in parallel as it already has been. This works
because most of the dependencies are handled by the early bootstrap
phases as well as 'libraries' and 'includes' phases. This lets
all of the SUBDIR build in parallel fine, such as bin/ and lib/. This
will not work if the user invokes 'all' though as we have dependencies
spread all over the system with no way to depend between them (except
for the dirdeps feature in the META_MODE build). Calling 'make all'
from the top-level is still useful at least when using SUBDIR_OVERRIDE.
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
The ordering of 'etc' in the install has a long history dating back to the
first time it was realized it needed to be "last" in r4486. That commit
still left it before LOCAL_DIRS though. By having it before LOCAL_DIRS
any manpages they install were not being added to the whatis database in the
install image. They would likely show up in the file after a periodic
rebuild of the file though.
Currently the whatis file is built by an 'afterinstall' hook in etc/Makefile
that calls share/man's 'makedb' target.
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
It was added in r152006 to handle serializing access of info/dir when
installing INFO files. We no longer support INFO files since r276551
though.
Sponsored by: EMC / Isilon Storage Division
The case of make(1) using a new /bin/sh issue was fixed in r173219 when ITOOLS
was introduced.
There are still issues with mid-install errors leaving a system unusable that
are currently non-trivial to solve. The safest ordering requires installing
rtld, libc and libthr (in that order) before anything else. We don't do that
now though. Much improvement is needed here still.
Discussed with: kip and kan (rtld/library ordering)
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
This was handled for libraries in r256842 but for some reason was missed
for files (bsd.prog.mk).
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
Relnotes: yes
This was causing files to be removed from the objdir when -n was used.
_worldtmp makes no sub-make calls.
A more comprehensive solution is coming involving fine-grained '+' where
appropriate.
Sponsored by: EMC / Isilon Storage Division
MFC after: 1 week
with the current behaviour of calling "distribution" in the etc target.
This allows mergemaster/etcupdate to still work when some configuration will be
moved to be handled in the same directories their source code lives in.
when running the build-tools stage.
The requirement is due to the -P flag used when running m4 from usr.bin/lex
Makefile to generate skel.c. With the old m4 that fails and the failure is
ignored, resulting in an empty(-ish) skel.c, which leads to later build
failures when the misconfigured new lex tool is run.
This enables building -current (and 10-stable after MFC) on a stable-8
system again.
MFC after: 3 days
Bootstrap tools exist for backwards compatibility support. DTrace tools
tools are also needed for cross builds, so belong in cross-tools.
Reviewed by: imp (earlier), markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2144
Stale CTF tools are a frequent source of DTrace issues, and they compile
quickly enough that the increase in build time is negligible.
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D3670
a one word variable, which is quite unexpected from documentation.
So, to avoid double installation of a single kernel, protect the extra
kernels loop with ${BUILDKERNELS:[#]} > 1 conditional.
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
from BUILDKERNELS list. This is more strict, since INSTALLKERNEL by
definition is the first word of BUILDKERNELS list. The previous
code failed if INSTALLKERNEL is a substring of additional kernel name.
Reviewed by: gjb
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
For most cases they are equivalent, but BINUTILS_BOOTSTRAP is a
BROKEN_OPTION on arm64 as the in-tree GNU binutils do not support it,
so we need a separate internal flag for ELF Tool Chain.
Reviewed by: andrew, brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3381
The option was added only to ease the transition from GNU Binutils to
ELF Tool Chain tools, and that process is now complete (for the viable
replacements). Noting the removal in UPDATING is sufficient as we have
not shipped a release with the option.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3240
changes to prevent the 'rescue: not found' errors from happening.
Bump FreeBSD_version to 1100078 since there's been no version bumps
since this change was made. Only people that installed since r284356
really need to do this bootstrapping, but since crunchgen needs to
bootstrap for other reasons, bumping the number was the simplest.
They need to be built and installed (including headers) prior to the
DTrace CTF tools.
Reviewed by: imp (as part of a larger change)
Sponsored by: The FreeBSD Foundation
This makes sysroot usable for cross building, it also removes the need for
_SHLIBDIRPREFIX (keeps its definition since picobsd uses it and I have no time
to test it)
Differential Revision: https://reviews.freebsd.org/D2920
Submitted by: imp, adrian
Tested by: adrian
This change among other things improve search capabilities over the manpages
allowing fine grain query.
A new build option WITHOUT_MANDOCDB has been added to keep the ancient version
of the database and the tools. The plan is to entirely remove this option before
11.0-RELEASE.
Differential Revision: https://reviews.freebsd.org/D2603
typos, and fixing the dependency when MK_LIBCPLUSPLUS != no
- `:D` operator evaluation is immediate, i.e. like .if defined(..). So r283159
was in effect a no-op commit.
- Fix dependency in MK_LIBCPLUSPLUS case in two ways:
-- lib/libc++ was the wrong dependency. It should have been libcxxrt.
-- lib/libc++ was missing __L, so again it was depending on the directory, not
the relevant .PHONY target.
Tested with: make tinderbox (amd64, arm, sparc64) and JFLAG=-j16
In collaboration with: bdrewery, imp, peter
BIG pointyhat to: ngie (for trying to commit things at 6am while staying up all
night working on other tasks)
This reduces the number of copy of sqlite we have to just one and easier
tracking version of sqlite
Differential Revision: https://reviews.freebsd.org/D2443
Reviewed by: imp, stas, bjk
- r277259 crunchide: Correct 64-bit section header offset
- r281674 crunchide: always include both 32- and 64-bit ELF support
With built-in cross-size support we also no longer need a special case
for cross-build crunchide.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2576
The appropriate subdirectories are handled by lib/csu/Makefile. There's
no need to duplicate this logic in Makefile.inc1 and lib/Makefile.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2523
(Makefile.inc1): add dependency of xinstall on libmd to
avoid failure of parallel bootstrap.
(lib/libmd/*.h): do not redefine symbols if already
defined as macros (libcrypt uses the same sources internally,
redefining symbols with a prefix of its own).
Fixes build failures caused by previous change to libmd.
Reported by: ian
Pointy hat to: thomas
if its set in the environement of each command seperately.
Move the PATH setting to the NXBMAKE variable so its picked up to find
the one-off gperf build for the native-xtools target.
Pointed Out by: ngie
enabled host. Build a one-off gperf and put it in the PATH for the rest
of the target so the ONE call to gperf by the gcc build picks it up and
DTRT.
Reviewed by: imp
make bootstrap-tools
On the plus side, this also greatly reduces complexity
MFC after: 1 week
Pointyhat to: ngie
Reported by: Willem Jan Withagen <wjw@digiware.nl>
stopped using kgzip in the release process. We no longer need to build
kgzip as a cross tool, and tests for RELEASEDIR are obsolete, so
remove both.
Differential Revision: https://reviews.freebsd.org/D2313
parallelization work done in r279197
- kerberos5/lib/libroken requires kerberos5/tools/make-roken to build
- kerberos5/tools/asn1_compile, kerberos5/tools/slc, and usr.bin/compile_et
require kerberos5/lib/libroken and kerberos5/lib/libvers
This race is incredibly evident when cross-building sparc64 on
ref10-amd64.freebsd.org
MFC after: 1 week
Pointyhat to: ngie
stage, just like for the regular world stage.
Reviewed by: rodrigc, imp, bapt, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D2187
As legacy executes "make installincludes" we don't want it to be
disabled by a src.conf setting.
Reviewed by: imp
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2143
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
This fixes C++ libraries not implicitly linking in libc++. This is
generally not an issue because the final linking with the compiled binary
will involve CXX via PROG_CXX or other means. It is however
inconsistent with libraries implicitly linking in libc and problematic
for trying to build libraries with '-z defs' to ensure all direct
dependencies are linked in.
libatf-c++ is currently the only consumer of this new feature.
Differential Revision: https://reviews.freebsd.org/D2039
Reviewed by: imp
Discussed with: bapt
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
The in-tree binutils does not support arm64, so will not work for the
forthcoming FreeBSD arm64 port. BROKEN_OPTIONS will include
BINUTILS_BOOTSTRAP, so provide a default CROSS_BINUTILS_PREFIX for this
case.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Dynamically figure out the list of targets based on tags passed on the mtrees
First sanity check that all packages have existing manifests
Generate the packages
Please note that for now the mtree needs more work as it has duplicate entries,
everything is not yet tagged
The packages now have generic entries and needs to be customize
inadvertently removed when support for external GCC was added.
Deprecate XFLAGS in favour of the newer XCFLAGS/XCXXFLAGS.
Tested with: make universe, make CROSS_COMPILER_PREFIX=/usr/bin/ buildworld
Reviewed by: imp, bapt
libarchive(3) doesn't support the new liblzma API yet, but this change
allows us to enable multi-threaded xz compression.
``make release'' should now finish in half the time on a machine with
several cores and fast disks (our typical build server).
This behaviour only applies when building a release and it doesn't
affect buildworld/installworld. To disable threaded xz compression,
set XZ_THREADS=1.
Reviewed by: gjb
Tested by: gjb
update paths; and include everything in the "base" distribution.
The "games" distribution being optional made sense when there were more
games and we had small disks; but the "games-like" games were moved into
the ports tree a dozen years ago and the remaining "utility-like" games
occupy less than 0.001% of my laptop's small hard drive. Meanwhile every
new user is confronted by the question "do you want games installed" when
they they try to install FreeBSD.
The next steps will be:
2. Removing punch card (bcd, ppt), phase-of-moon (pom), clock (grdc), and
caesar cipher (caesar, rot13) utilities. I intend to keep fortune, factor,
morse, number, primes, and random, since there is evidence that those are
still being used.
3. Merging src/games into src/usr.bin.
This change will not be MFCed.
Reviewed by: jmg
Discussed at: EuroBSDCon
Approved by: gjb (release-affecting changes)
This brings support for multi-threaded compression. This brings close
N times faster compression where N is the number of CPU cores.
Because of this, liblzma now depends on libthr.
Soon libarchive will be modified to use the new lzma API.
Thanks to antoine@ for the exp-run.
Differential Revision: https://reviews.freebsd.org/D1786
Reviewed by: bapt
The version scheme used is the following:
For stable/current branches:
${REVISION}.sYYYYMMDDhhmmss
s standing for snapshot
For releases branches:
${REVISION}_${PATCHLEVEL}
When packaging the kernel 2 different package are created per kernel
release (only contains the regular kernel and modules)
debug (contains the .symbols files)
Note that package the kernel (packaging world will follow the same rule) can
only by passing -DNO_ROOT to the build (hence can be done as a regular user)
To package the kernel:
make buildkernel
make distributekernel DESTDIR=/somewhere -DNO_ROOT
make kernel-pkgs DESTDIR=/somewhere -DNO_ROOT
The packages will be created inside the DESTDIR
Addr2line is not required for the build, and a per-arch binary is no
longer required with the switch to the ELF Tool Chain. However, building
these tools during the cross tools stage can be useful for developers
who cross build HEAD from stable/10, and adds very little to the build
time.
Reviewed by: ian, imp
Differential Revision: https://reviews.freebsd.org/D1583
To be able to info pages consider installing texinfo from ports print/texinfo or
via pkg: pkg install texinfo
Differential Revision: https://reviews.freebsd.org/D1409
Reviewed by: emaste, imp (previous version)
Relnotes: yes
Previously it also disabled building elftoolchain bootstrap tools such as
strip(1).
Differential Revision: https://reviews.freebsd.org/D1398
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
ensure that building on a host without makeinfo (i.e. a host where
make delete-old -DWITHOUT_INFO was run), then building with MK_INFO == yes
doesn't manifest in build errors when building info pages
This manifested itself like the following when I was build testing an MFC
change on stable/10:
makeinfo --no-split -I /usr/src/gnu/lib/libregex/doc -I /usr/src/gnu/lib/libregex/doc regex.texi -o regex.info
makeinfo: not found
*** [regex.info] Error code 127
make[6]: stopped in /usr/src/gnu/lib/libregex/doc
1 error
Tested on a head VM without makeinfo installed and by building with MK_INFO=yes
MFC after: 1 week
The work in r258233 hardcoded the assumption that tests was the last component
of the tests tree by pushing tests as an explicit prefix for the paths in
BSD.tests.dist and /usr was the prefix for all tests, per BSD.usr.dist and all
of the mtree calls used in Makefile.inc1. This assumption breaks if/when one
provides a custom TESTSBASE "prefix", e.g. TESTSBASE=/mytests .
One thing that r258233 did properly though was remove "/usr/tests" creation
from BSD.usr.dist -- that should have not been there in the first place. That
was an "oops" on my part for the work that was originally committed in r241823
MFC after: 2 weeks
Phabric: D1301
Reviewed by: imp
Sponsored by: EMC / Isilon Storage Division
when strip gets replaced at install time by adding it to ITOOLS for the
default usr.bin/xinstall STRIP_CMD
This will fix the failure noted in this Jenkins build step:
https://jenkins.freebsd.org/job/Build-UFS-image/688/
This will also fix the issue reported by alfred@ dealing with installing on
targets that differ from build hosts (e.g. installing on i386/i386 when built
on amd64/amd64)
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
This will fix installation with differing host targets in installworld, so
one can build i386/i386 on an amd64 host, then install to an i386/i386 target
Reported by: alfred
Phabric: D1280
MFC after: 1 week
This will unbreak the build when "env MK_CXX=no make delete-old" has been run
on the build host post-r272849
Tested with the following commands:
/bin/sh
export __MAKE_CONF=/dev/null SRCCONF=/dev/null
export MK_CLANG=no MK_CLANG_BOOTSTRAP=no MK_GCC=yes MK_GCC_BOOTSTRAP=yes
export MK_GNUCXX=yes TARGET=armv6 TARGET_ARCH=arm make xdev
make toolchain
make xdev-build
sudo -E make xdev-install
/usr/armv6-freebsd/usr/bin/cc -dumpmachine | grep arm
X-MFC with: r272849
Reported by: Dan Raymond <draymond@foxvalley.net>, gjb
if/when MK_CXX == no and make delete-old has been run on the build host,
post-r272849
Tested with the following command:
% sudo env MK_CLANG=no MK_CLANG_BOOTSTRAP=no MK_GCC=yes MK_GCC_BOOTSTRAP=yes \
MK_GNUCXX=yes make xdev
Set WITH_ELFTOOLCHAIN_TOOLS in src.conf to use the elftoolchain version
of the following tools:
* addr2line
* elfcopy (strip / mcs)
* nm
* size
* strings
Reviewed by: bapt (earlier version)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D1224
comes after share in SUBDIR in Makefile.inc1, the build will fail when vi is not
installed on the build host
Run build-tools for usr.bin/vi and install ex, etc to WORLDTMP to enable building
share/termcap on hosts that don't have nvi installed on them
