FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F14.2 2023-08-22T04:00:45Z 2023-08-22T04:00:45Z John Baldwin jhb@FreeBSD.org 2023-08-22T04:00:45Z urn:sha1:834f73d253581dba80a2d67a7c06b102b78c8a58 This fixes make UNIVERSE_TOOLCHAIN=yes with libcompats. Reviewed by: jrtc27 Differential Revision: https://reviews.freebsd.org/D41535 2023-08-16T17:55:03Z Warner Losh imp@FreeBSD.org 2023-08-16T17:55:03Z urn:sha1:d0b2dbfa0ecf2bbc9709efc5e20baf8e4b44bbbf Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/ 2023-08-10T23:48:01Z Jessica Clarke jrtc27@FreeBSD.org 2023-08-10T23:48:01Z urn:sha1:8aaa1230899239a90f35e73436377a6f5f79bbf9 Back when Makefile.lib32 was turned into Makefile.libcompat, a typo was introduced; it should have been LIBCOMPATDTRACE, but instead gained a dollar sign in it as LIB$COMPATDTRACE (and with COMPATDTRACE not being defined, was equivalent to ${LIB:U${DTRACE}}). This then meant it was not converted to LIB${_LIBCOMPAT}DTRACE in 91d7edd549f5 ("Generalise libcompat to be a list rather than a single option") and instead left broken. Belatedly fix this long-standing seemingly-inconsequential bug. Fixes: dba75e9fa5a9 ("Move Makefile.lib32 to Makefile.libcompat and generalize it.") 2023-08-01T21:01:57Z John Baldwin jhb@FreeBSD.org 2023-08-01T21:01:57Z urn:sha1:1c02497648bdf61a43dd271f6f9171a037046d8e make universe builds a cross toolchain under HOST_OBJTMP/tmp via the universe-toolchain target. However, doing a plain 'make buildworld' after a universe/tinderbox run (e.g. to reproduce a failure and test the fix for it), will try to build a new cross toolchain under OBJTMP/tmp which can be tedious. This commit adds a make variable (UNIVERSE_TOOLCHAIN) which can be used similar to CROSS_TOOLCHAIN to request an external toolchain. If this variable is set (value doesn't matter), the the universe toolchain is used as an external toolchain. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D40777 2023-07-25T23:59:52Z Mike Karels karels@FreeBSD.org 2023-07-25T23:59:52Z urn:sha1:a1b67573130114257fdd443c4ec9b54fbe2e5843 Enable LIB32 option on aarch64, defaulting to YES; it had defaulted to "broken". Add required variables for how to compile lib32 on arm. Use /usr/include/arm for armv7 (32-bit) headers, analogous to /usr/include/i386 on amd64. Omit libomp from lib32; it is not supported on armv7. Reviewed by: jrtc27 Differential Revision: https://reviews.freebsd.org/D40945 2023-07-14T04:34:03Z Jessica Clarke jrtc27@FreeBSD.org 2023-07-14T04:34:03Z urn:sha1:5d4f8df451aa942701ecfced80516f3584b589d9 bmake's :Q is for quoting outside of double quotes, but here is inside double quotes, and as a result it ends up quoting characters that don't have a special meaning inside double quotes. On the surface this would seem harmless, but POSIX sh has a strange behaviour (differing from outside double quotes) that, inside double quotes, a backslash before a character that never has a special meaning inside double quotes is passed through. As a result, should LIB${_LIBCOMPAT}CFLAGS contain something like -DFOO\(x\)=x, we would form "... -DFOO\\\(x\\\)=x ...", which would be parsed as -DFOO\\(x\\)=x, since the parentheses are never special inside double quotes (but the backslash itself is), not the original -DFOO\(x\)=x as intended. Instead, construct the whole string as a bmake expression and use :Q on that, without the manual double quotes around everything. Note that the :L modifier lets you treat an expression like a variable expansion and apply modifiers to it, i.e. ${expr:L:...} is the same as tmp=expr ${tmp:...} (in essence, ignoring possible differences due to deferred substitution). Improves: 537f945fc89f ("Makefile.libcompat: Quote CFLAGS and CXXFLAGS for sub-make") 2023-07-14T01:36:04Z Jessica Clarke jrtc27@FreeBSD.org 2023-07-14T01:36:04Z urn:sha1:0a5e35a7b1811308bcb2aa2e6c7e7bd49dfc9770 Currently we only pass MK_INCLUDES=no for distribute and install, since it's only in LIB${_LIBCOMPAT}IMAKE, which means that we enable includes during libraries and thus install includes into worldtmp, despite it being shared these days across native and libcompats. This also means we're at risk of having headers needed for building against a libcompat that don't get installed to the system, but do end up being installed to worldtmp. In particular, lib/msun has different fenv.h for aarch64 and arm, so aarch64 will need arm's copy when it grows lib32 support, and this would be installed to worldtmp, but not to the system, meaning any programs that use fenv.h wouldn't be able to be built. Instead, be consistent, and don't install includes at all during any of the libcompat phases, so that we can detect these issues and ensure any needed headers are installed for both worldtmp and the system. Reviewed by: brooks Differential Revision: https://reviews.freebsd.org/D41030 2023-07-09T17:46:12Z Jessica Clarke jrtc27@FreeBSD.org 2023-07-09T17:46:12Z urn:sha1:537f945fc89fab53f60fee07ac42c8aeab704ce7 Currently none of the words in these require quoting, but a future commit will add words that do, thus we should make sure to quote each word so the shell doesn't mangle them before calling the sub-make. (Note that :@var@expr@ is the bmake syntax for map, replacing each word with expr's evaluation, with var containing the input word) Reviewed by: emaste, brooks, jhb Differential Revision: https://reviews.freebsd.org/D40921 2023-06-27T23:10:49Z Jessica Clarke jrtc27@FreeBSD.org 2023-06-27T23:10:49Z urn:sha1:91d7edd549f52d09dbb12ecf5f0cf2298287f1c8 Whilst the kernel can support any number of COMPAT_FOO, world can only build a single libfoo. Upstream this isn't such an issue, since the only option is lib32 anyway, but downstreams, such as CheriBSD, may wish to support multiple at the same time. Thus, adjust the top-level Makefiles to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and adjust bsd.compat.mk to support this use-case. For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and refer to the requested compat's, preserving the current interface. For the top-level Makefiles those variables are no longer set (since there is no longer "the" compat) and only the per-compat ones are available. Reviewed by: brooks, jhb, imp Differential Revision: https://reviews.freebsd.org/D40571 2023-06-27T23:10:30Z Jessica Clarke jrtc27@FreeBSD.org 2023-06-27T23:10:30Z urn:sha1:10afc5eada472f7903238c7021a00f722f49a789 Currently Makefile.libcompat queries a few MK_FOO variables to determine what is being built. However, it is plausible (and indeed, downstream in CheriBSD, this is the case) that these may vary between the native and the compat architecture. In order to correctly determine their values for the compat architecture, we need to defer their evaluation until we are in the compat sub-make where src.opts.mk will give us the right value for the compat MACHINE_ARCH. Reviewed by: brooks, jhb, imp Obtained from: CheriBSD Differential Revision: https://reviews.freebsd.org/D40570