The top-level Makefile passes -m to its sub-makes in order to ensure
they use the in-tree mk files in share/mk, but the top-level make itself
has to rely on whatever environment the bmake used has. For FreeBSD, we
configure the system bmake with .../share/mk:/usr/share/mk, which means
it will pick up src's share/mk whenever run from within the src tree,
but currently for non-FreeBSD we configure our bootstrap bmake only with
bmake's own mk files. This is mostly compatible, with two exceptions:
1. "targets" runs at the top level, but needs TARGET_MACHINE_LIST and
the corresponding MACHINE_ARCH_LIST_${target}, otherwise it will just
print an empty list.
2. "universe" and "universe-toolchain", when run at the top level (i.e.
not via the various wrappers around universe like tinderbox), end up
failing in universe-toolchain itself with:
bmake[1]: "/path/to/freebsd/share/mk/src.sys.obj.mk" line 112: Cannot use MAKEOBJDIR=
Unset MAKEOBJDIR to get default: MAKEOBJDIR='${.CURDIR:S,^${SRCTOP},${OBJTOP},}'
By including .../share/mk in the default sys path like FreeBSD's system
bmake we ensure that we get the in-tree mk files for the top-level make,
not just sub-makes, and avoid such issues.
Note that we cannot (yet) stop using the installed mk files, since the
MAKEOBJDIRPREFIX check in Makefile runs in the object directory and uses
env -i, thereby losing the MAKESYSPATH exported by src.sys.env.mk. Other
such issues may also exist, though are likely rare if so.
Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D41544
We currently assume that any existing bootstrapped bmake binary will
work, but this means it never gets updated as contrib/bmake is, and
similarly we won't rebuild it as and when the configure arguments given
to boot-strap change. Whilst the former isn't necessarily a huge problem
given WANT_MAKE_VERSION rarely gets bumped in Makefile, having fewer
variables is a good thing, and so it's easiest if we just always keep it
up-to-date rather than trying to do something similar to what's already
in Makefile (which may or may not be accurate, given updating FreeBSD
gives you an updated bmake, but nothing does so for our bootstrapped
bmake on non-FreeBSD). The latter is more problematic, though, and the
next commit will be changing this configuration.
We thus now add in two checks. The first is to compare MAKE_VERSION
against _MAKE_VERSION from contrib/bmake/VERSION. The second is to
record at bootstrap time the exact configuration used, and compare that
against what we would bootstrap with.
Reviewed by: arichardson, sjg
Differential Revision: https://reviews.freebsd.org/D41556
Systems that predate 971bac5ace ("kbd: consolidate kb interfaces
(phase one)") cannot build kbdcontrol since kbdelays and kbrates moved
to sys/kbio.h. Moreover, on non-FreeBSD, it requires all kinds of ioctls
and sysctls that are highly FreeBSD-specific to build, but we use it as
a bootstrap tool to generate the keymaps used by some kernels (LINT ones
in particular). Thus, when bootstrapping kbdcontrol, disable everything
that's not needed for that singular use, and use the in-tree kbio.h to
get the definitions of the necessary structures.
This allows KBDMUX_DFLT_KEYMAP, UKBD_DFLT_KEYMAP and ATKBD_DFLT_KEYMAP
to be enabled when building on non-FreeBSD, and thus LINT kernels.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D41541
- Prune headers and tests no longer installed after the upgrade.
- Remove GoogleTest-related files when MK_GOOGLETEST == no.
- Disable `-Werror` with gcc to unbreak the gcc12 CI run with
`lib/googletest`. Any issues found by g++ will be filed
upstream and hopefully resolved in a future version.
- Remove clang -Werror issues which are resolved in version 1.14.0 to
avoid masking valid issues.
MFC after: 1 week
MFC with: 28f6c2f292
This change updates `make delete-old` to account for files installed by the
following options:
- MK_BSDINSTALL
- MK_DMAGENT
- MK_EXAMPLES
- MK_SENDMAIL
MFC after: 2 weeks
9600 was a standard baud rate decades ago, but 115200 is now more common
so choose defaults that are useful to the largest number of users.
Note that boot0sio does not support rates above 9600 so it remains
unchanged.
Reviewed by: bz, imp, manu
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36295
Use at your own risk, but this will remove $FreeBSD$ from your tree. It
does commits and tries to be at least a little smart about it.
Sponsored by: Netflix
At the moment, several Makefiles under tests/ do not correctly generate
.depend files, which can lead to link errors when doing incremental
(e.g. WITHOUT_CLEAN) builds:
ld: error: undefined symbol: testing::internal::g_linked_ptr_mutex
>>> referenced by gtest-port.h:2137 (/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/internal/gtest-port.h:2137)
>>> mockfs.o:(testing::internal::linked_ptr_internal::depart())
>>> referenced by gtest-port.h:2139 (/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/internal/gtest-port.h:2139)
>>> mockfs.o:(testing::internal::linked_ptr_internal::depart())
>>> referenced by gtest-port.h:2139 (/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/internal/gtest-port.h:2139)
>>> mockfs.o:(testing::internal::linked_ptr_internal::depart())
>>> referenced 3 more times
For the time being, put in a depend-cleanup.sh workaround for this.
Reported by: des
Reviewed by: emaste
Fixes: 28f6c2f292
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D41476
Toolchain components were historically statically linked. They became
normal dynamically linked executables in commit 6ab18ea64d. There is
no need to keep a special case build option for the toolchain; users who
want statically linked toolchain (or any other) components can use the
existing NO_SHARED knob.
Reviewed by: dim, sjg
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41266
Prior to Clang 13 (e.g. in the Clang 11 present in 13.0-RELEASE), the
resource directory logic for FreeBSD was broken and would not resolve
symlinks, meaning symlinks would only work if in a directory next to the
containing lib directory. Therefore we cannot even use a symlink for
worldtmp, we have to make a wrapper script that execs the real binary
via an absolute path.
Reported by: markj
Reviewed by: markj
Fixes: 65f28f63a7 ("tools/build: Create toolchain symlinks for non-absolute compiler/linker")
Differential Revision: https://reviews.freebsd.org/D41238
This option is a blanket for all the DTrace-related software. The option
when enabled passes in -fsanitize=address -fsanitize=undeifned, enabling
ASAN and UBSAN in the following components:
- libdtrace
- dtrace(1)
- lockstat(1)
- plockstat(1)
The option defaults to "no" and is intended as a developer aid.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D41157
If any of the toolchain variables are not absolute then we need to
create a symlink in WORLDTMP/legacy/bin in order to make them available
during a BUILD_WITH_STRICT_TMPPATH build.
Reviewed by: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D41188
By passing through _ALL_libcompats we can avoid hard-coding the list of
libcompats in depend-cleanup.sh. This cleanup also makes clean_dep
shorter by using a loop instead of handling each case explicitly (at the
expense of slightly tweaked logging).
Reviewed by: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D41187
The removal of the sparc64 support in February 2020 obsoleted the
VTOC8 partitioning scheme as no other FreeBSD platform makes use
of it. Moreover, the code is bitrotting as nothing defines e. g.
LOADER_VTOC8_SUPPORT any more and, thus, should go now, too. With
this change, the following commits are reverted as far as VTOC8
is concerned and parts haven't already previously been deleted
along with prior sparc64 removals:
094fcb157da7d366e958ba8d50d08b
The alignment example d9711c28ef
added to the VTOC8 section of gpart.8 is folded into the MBR one.
This should finally conclude the deorbit of sparc64-specific bits.
We had joy, we had fun
we ran Unix on a Sun.
But that source and the song
of FreeBSD have all gone.
Credits to Michael Bueker for the original "Unix on a Sun" and Rod
McKuen for the "Seasons in the Sun" lyrics.
Perforce has been retired since 2019 (commit feea78990c), so there is
no need anymore to keep perforce tools. Plus, there is no need to
mention perforce admin.
Reviewed by: emaste, Olivier Certner
Differential Revision: https://reviews.freebsd.org/D41106
These are useful for testing new additions to the script. Whilst here,
harden the script a little and improve error messages.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D31007
We run depend-cleanup.sh twice during the build. The second time is the
normal run, where we run it under WMAKEENV and thus have CROSSENV's
MACHINE(_ARCH)=${TARGET(_ARCH)} in the environment. However, the first
time is for bootstrap-tools, where it's run under BMAKEENV and we don't
have any assignments to MACHINE(_ARCH) in the environment, meaning the
script sees them as unset. In practice this doesn't matter since the
only use doesn't apply to bootstrap-tools, but it could be a future
issue. Thus, explicitly export them for depend-cleanup.sh and have the
script verify they're set.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D40968
Now that depend-cleanup.sh handles 32-bit dependencies a bit better, get
rid of the stale ffs.S ones, otherwise an incremental build on amd64
will fail with:
cc: error: no such file or directory: '/usr/src/lib/libc/i386/string/ffs.S'
Fixes: ee8b0c436d
For example with the recent removal of ffs.S for 32-bit arm and i386,
the egrep in clean_dep() did not find any files to remove, even if you
added a "clean_dep lib/libc ffs S" line. This is because it will never
find the ffs.S filename in the 64-bit .depend files for libc.
Split the searching and removing of 32-bit dependencies and objects into
a separate part to cope with this. This can be used similarly later on,
for other bitnesses.
MFC after: 3 days
This can be run inside a bhyve guest to query the value of fwctl
nodes. Note that fwctl in bhyve only supports a single hw.ncpu node.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D40803
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
