FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F14.0 2023-09-07T03:33:32Z 2023-09-07T03:33:32Z John Baldwin jhb@FreeBSD.org 2023-08-25T23:22:01Z urn:sha1:73e5df026288891134e9fa205ab30455abdd5c01 Two more profile libraries that should be removed by WITHOUT_PROFILE. Found when upgrading a stable/13 VM to stable/14. Approved by: re (gjb) (cherry picked from commit 023ef8015ee6c4e76b63db310800a0f2512fea72) 2023-08-23T16:56:56Z Jessica Clarke jrtc27@FreeBSD.org 2023-08-23T16:56:56Z urn:sha1:62f243acea24f52c6420720db615535045489c50 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 2023-08-23T16:56:50Z Jessica Clarke jrtc27@FreeBSD.org 2023-08-23T16:56:50Z urn:sha1:69cfdc81ea7bdfe1e7300a7e1106419156aee434 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 2023-08-22T20:00:28Z Jessica Clarke jrtc27@FreeBSD.org 2023-08-22T20:00:28Z urn:sha1:968a3db7151644bda2036e1be8d4c536220b318f Systems that predate 971bac5ace7a ("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 2023-08-22T17:53:13Z Jessica Clarke jrtc27@FreeBSD.org 2023-08-22T17:53:13Z urn:sha1:5157b451c65480deecbc0e7c223684830a4af7ce 2023-08-22T17:52:57Z Jessica Clarke jrtc27@FreeBSD.org 2023-08-22T17:52:57Z urn:sha1:3b4da25ead62c346d05199bc96cd6935e896849f 2023-08-22T01:37:20Z Warner Losh imp@FreeBSD.org 2023-08-22T01:37:13Z urn:sha1:b376ef36f569c85cbd135349b6e8b9737bba5d2a 2023-08-19T07:29:09Z Peter Holm pho@FreeBSD.org 2023-08-19T07:29:09Z urn:sha1:0d30f3afa62b4740810006476eb9de0c480619a1 2023-08-19T07:28:10Z Peter Holm pho@FreeBSD.org 2023-08-19T07:28:10Z urn:sha1:f322816aafa759d618ff89da266c038d0694e189 2023-08-19T02:33:58Z Enji Cooper ngie@FreeBSD.org 2023-08-18T11:28:13Z urn:sha1:0c785f06020f3b02e34c97eb27fecd3af8eb2a7b - 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: 28f6c2f292806bf31230a959bc4b19d7081669a7