Main difference between older Zen variants is that this supports AVX-512
Reviewed by: imp (previous version), emaste
Approved by: emaste
Differential Revision: https://reviews.freebsd.org/D41331
- 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
GoogleTest 1.14.0 now requires C++14 to build. Change
`googletest.test.inc.mk` to reflect this requirement.
Adjust the build integration logic to handle the new version of
GoogleTest (add/remove headers/sources as needed).
Tighten down warnings via `CXXFLAGS.clang` instead of ignoring all
warnings. Some new warnings snuck in after I did my last round of fix
submissions upstream.
Also address some overlinking added in the previous version import by
removing superfluous libraries.
===============================
Expect WhenDynamicCastToTest.AmbiguousCast to fail
This change reapplies the expected failure from 1.10.0.
Ref: https://github.com/google/googletest/issues/2172
MFC after: 2 weeks
Reviewed by: asomers, emaste
Differential Revision: https://reviews.freebsd.org/D41399
Merge commit '8ef491440fcaec96f899d73e08873426c78583a4' into googletest-v1.14.0-import
Use ?= when setting CROSS_TARGET_FLAGS so we do not override it
if another file already has set it.
Reviewed by: sjg
Obtained from: Juniper Networks, Inc.
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
Per discussions over how to lighten the load of armv6, move it to an
extra arch. You can still build TARGET_ARCH=armv6 if you desire, but
it won't be built as part of 'make universe' without -DEXTRA_TARGETS.
Sponsored by: Netflix
Initial libs such as csu are always built (.PHONY), and their
installation to WORLDTMP was causing all the subsequent libraries to
be considered out-of-date even when in reality they were not. Use
install -C more consistently everywhere to avoid unnecessarily
updating the mtimes in WORLDTMP, fixing this problem.
This cut down my no-change buildworld time from 30 to 15 seconds.
Fixes: https://lists.freebsd.org/pipermail/freebsd-current/2016-May/061481.html
TODO.1
Reviewed by: sjg
Sponsored by: https://www.patreon.com/valpackett
Differential Revision: https://reviews.freebsd.org/D39980
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
Note that the pattern for matching is made slightly more specific, so as
to permit libcompats where one is a prefix of another (e.g. CheriBSD has
lib64 and lib64c).
Reviewed by: brooks, jhb, emaste
Differential Revision: https://reviews.freebsd.org/D41185
Adding these to a new bsd.compat.pre.mk will allow other parts of the
tree to iterate over the set of possible libcompats (upper and/or lower)
rather than having to hard-code the list.
Reviewed by: brooks, jhb, emaste
Differential Revision: https://reviews.freebsd.org/D41178
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
Whilst ^ and $ are supported with C, those are special cases, and
general regex syntax like groups and alternations are not. Use the
correct modifier so we get a version number out that's not 0 (which is
what happens when it can't be parsed by the later code).
Fixes: c4177f5b41 ("bsd.linker.mk: Handle Xcode 15 linker identification")
MFC after: 1 week
The upcoming Xcode 15 introduces a new linker (called ld-prime or ld-new
in some documentation) to replace the classic ld64, which we need to
handle.
Previously, the linker would identify itself as:
@(#)PROGRAM:ld PROJECT:ld64-<version>
Now, there are two cases. When the classic ld64 is in use, it identifies
itself as:
@(#)PROGRAM:ld-classic PROJECT:ld64-<version>
When the new linker is in use, it identifies itself as:
@(#)PROGRAM:ld PROJECT:dyld-<version>
Thus, tweak the detection to allow a -classic suffix in the PROGRAM
string and to allow a dyld- prefix instead of an ld64- prefix on the
version number in the PROJECT string.
MFC after: 1 week
lld assumes -znoexecstack by default whereas ld.bfd still defaults to
-zexecstack in the absence of .note.GNU-stack annotations. Adding the
flags centrally avoids having to patch various libraries in the tree
as one-offs (e.g. OpenSSL 3 is the current thing generating new
warnings with ld.bfd).
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D41120
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: emaste, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40932
Currently the only way to detect for a libcompat build is to consult
whether COMPAT_32BIT is defined (or equivalent, for downstreams with
other libcompats or past releases with libsoft as COMPAT_SOFTFP). There
are two issues with this:
1. COMPAT_32BIT is a new naming scheme that doesn't match the libcompat
name, which is unnecessary deviation.
2. When multiple libcompats exist, everywhere that needs to detect a
libcompat must check each variable in turn, despite the fact that it
normally just wants to know if this is a libcompat build and perhaps
what ${LIBCOMPAT} and/or ${libcompat} are for it.
As a result, far too many places in the tree need to know about the set
of possible libcompats.
Instead, introduce two new CPP and sub-make variables, COMPAT_LIBCOMPAT
and COMPAT_libcompat, which give the values for ${LIBCOMPAT} and
${libcompat} respectively, so that uses can be made parameterised. For
when code really does need to know the specific libcompat, Makefiles can
perform a string comparison, but the C preprocessor cannot, so introduce
an additional CPP-only COMPAT_LIB${LIBCOMPAT} which is intended to
replace the inconsistently-named COMPAT_32BIT (which will be removed in
future). Uses of this new variable should still be kept to a minimum,
however, given the code duplication needed for new libcompats.
Reviewed by: emaste, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40922
This patch fixes a bug which prevents building libthr without
_PTHREADS_INVARIANTS defined. The default remains to build libthr
with -D_PTHREADS_INVARIANTS. However, with this patch, if one builds
libthr with WITHOUT_PTHREADS_ASSERTIONS=true then the latency to
acquire+release a default pthread mutex is reduced by roughly 5%, and a
robust mutex by roughly 18% (as measured by a simple synthetic test on a
Xeon E5-2697a based machine).
Reviewed by: jhb, kib, mjg
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D40900
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
As of commit fd71da37d4 we no longer have an `as` in the default
toolchain. Although we do not make use of this rule in the base system
some ports or downstream projects might. Use `cc -x assembler` instead
of as.
Reviewed by: arichardson
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35859
Print a warning if we try to WITHOUT_ an option which is marked as
"required" (and forced on).
Suggested by: emaste, imp
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D40613
This is already present in sys/conf/kern.mk and can be used to
selectively disable -Wunused-but-set-variable.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D40663
At this point CAPSICUM and CASPER are merely forced on via the newly
added __REQUIRED_OPTIONS list; after stable/14 branches I'll sweep
the tree for MK_{CAPSICUM,CASPER}.
This change will not be MFCed.
Discussed on: freebsd-arch
Differential Revision: https://reviews.freebsd.org/D40592
Options on this list will be forced to 'yes'. This is intended for use
as a transitional measure when an option is ceasing to be optional,
before all of the associated make logic is removed.
Differential Revision: https://reviews.freebsd.org/D40590
* Replace hand-rolled input tokenizer with openpam_readlinev() which supports line continuations and has better quoting and escaping.
* Simplify string handling by merging struct clnt_str and struct srvr_str into just struct tac_str.
* Each server entry in the configuration file can now have up to 255 AV pairs which will be appended to the ones returned by the server in response to a successful authorization request.
This allows nss_tacplus(8) to be used with servers which do not provide identity information beyond confirming the existence of the user.
This adds a dependency on libpam, however libtacplus is currently only used by pam_tacplus(8) (which is already always used with libpam) and the very recently added nss_tacplus(8) (which is extremely niche). In the longer term it might be a good idea to split this out into a separate library.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: pauamma_gundo.com, markj
Differential Revision: https://reviews.freebsd.org/D40285
Relnotes: yes
Now that gcc >= 12 supports -ftrivial-auto-var-init, add it to
bsd.compiler.mk's "init-all" feature.
PR: 271047
Reviewed by: emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D40208
As of clang 16, the -ftrivial-auto-var-init=zero option no longer needs
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
to enable the option. Only add it for older clang versions.
PR: 271047
Reviewed by: emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D40208
While *most* projects need only DEP_MACHINE for host, there is always
an exception. So we allow for TARGET_SPEC_VARS.host to be a subset of
TARGET_SPEC_VARS. The default will *just work* for most projects.
We set DEP_TARGET_SPEC_VARS and hence DEP_TARGET_SPEC based on
DEP_MACHINE. Allow for M_dep_qual_fixes.host to be different too and
take care to apply the right set.
Add more comments to explain what and why.
Ensure OBJROOT ends in / or - (/ preferred).
Export OBJTOP if level > 0
this avoids the issue with bmake/unit-tests.
Check if we have to override MAKEOBJDIR
and if so, put it into env correctly.
Rather than define the TARGETS and TARGET_ARCHES in src/Makefile
put them in sys.machine.mk so they can also be leveraged by
non-top-level builds.
We have TARGET_MACHINE_LIST as the list of MACHINES we build for.
For each MACHINE we have a MACHINE_ARCH_LIST_${MACHINE}
and the first entry of each list is used as default for
MACHINE_ARCH_${MACHINE}
We can now remove a bunch of MACHINE_ARCH.* handling from
local.sys.dirdeps*mk
Reviewed by: imp
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D40083
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
When originally implemented, there was no distinction between
DIRDEPS_BUILD and META_MODE, they were one and the same.
META_MODE however is useful by itself, but since meta.sys.mk
had lots of settings related to DIRDEPS_BUILD its use was limited
to DIRDEPS_BUILD.
Move (most) DIRDEPS_BUILD related items to sys.dirdeps.mk
so that meta.sys.mk can be used for just META_MODE.
There is of course some bluring of the lines, so settings remain
in meta.sys.mk
Add MK_META_ERROR_TARGET to enable the META_MODE .ERROR target
independent of DIRDEPS_BUILD, it copies failed .meta files to ${SB}/error
to make it easier to identify the cause of build failures.
Since sys.dirdeps.mk should be included first, most of
local.meta.sys.mk becomes local.sys.dirdeps.mk
and some other bits need to move to local.sys.dirdeps.env.mk
Also fix dirdeps.mk to not add CURDIR to DIRDEPS when it is SRCTOP.
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D40053
We're never going to support EFI booting on i386 (32-bit). Start to
decommission it, since it's never worked.
Sponsored by: Netflix
Reviewed by: tsoome, emaste
Differential Revision: https://reviews.freebsd.org/D40011
