clang-format is enabled conditional on either WITH_CLANG_EXTRAS or
WITH_CLANG_FORMAT. Some sources in libclang are build conditional on
either rule, and obviously the clang-format binary itself depends on the
rule.
clang-format could still use a manual page.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D25427
As of r361857 all BINUTILS options are disabled by default - ports
have been changed to depend on binutils if they require GNU as, and
all base system assembly files have been switched to use Clang's
integrated assembler.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
The retirement of obsolete binutils 2.17.50 has been in progress for
quite some time. All tools other than GNU as were removed prior to this
commit, and it was built only on amd64 - installed as /usr/bin/as, and
used as a bootstrap tool.
The amd64 exp-run has completed and failures have now been addressed in
the individual ports, so disable it by default.
PR: 233611, 205250 [exp-run]
Sponsored by: The FreeBSD Foundation
The retirement of obsolete binutils 2.17.50 has been in progress for
quite some time. All tools other than GNU as were removed prior to this
commit, and it was built only on two archs:
i386, installed as /usr/bin/as
amd64, installed as /usr/bin/as and as a bootstrap tool
The i386 exp-run has completed and failures have been addressed in the
individual ports, so disable it there.
PR: 233611, 205250 [exp-run]
Sponsored by: The FreeBSD Foundation
r316063 installed pf's embedded libevent as a private lib, with headers
in /usr/include/private/event. Unfortunately we also have a copy of
libevent v2 included in ntp, which needed to be updated for compatibility
with OpenSSL 1.1.
As unadorned 'libevent' generally refers to libevent v2, be explicit that
this one is libevent v1.
Reviewed by: vangyzen (earlier)
Differential Revision: https://reviews.freebsd.org/D17275
ports/devel/linux_libusb builds FreeBSD libusb with GCC 4.8.5
from devel/linux-c7-devtools. Restore the tests for older GCC
in bsd.sys.mk to accomodate such ports.
Reported by: tijl
Sponsored by: Dell EMC Isilon
-development is long and awkward, and is also inconsistent with prior art
from the Linux world, which uses -dev (Debian) or -devel (Red Hat). Follow
the Debian convention, and similarly for debug info packages.
Also remove redundant pkgbase development tag from includes. We already tag
include files with package=runtime,dev; there is no need to separately tag
them as dev.
Discussed with: bapt
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24139
Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions
for older compilers.
Reviewed by: imp (earlier version), emaste, jhb
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D24802
BINUTILS is needed only for ports, and will be disabled once the failing
ports are addressed (likely by growing a binutils dependency).
BINUTILS_BOOTSTRAP is needed only on amd64, for skein_block_asm.s. There
is no need to enable it on i386.
This will all be removed before FreeBSD 13.0.
Save and restore (also known as suspend and resume) permits a snapshot
to be taken of a guest's state that can later be resumed. In the
current implementation, bhyve(8) creates a UNIX domain socket that is
used by bhyvectl(8) to send a request to save a snapshot (and
optionally exit after the snapshot has been taken). A snapshot
currently consists of two files: the first holds a copy of guest RAM,
and the second file holds other guest state such as vCPU register
values and device model state.
To resume a guest, bhyve(8) must be started with a matching pair of
command line arguments to instantiate the same set of device models as
well as a pointer to the saved snapshot.
While the current implementation is useful for several uses cases, it
has a few limitations. The file format for saving the guest state is
tied to the ABI of internal bhyve structures and is not
self-describing (in that it does not communicate the set of device
models present in the system). In addition, the state saved for some
device models closely matches the internal data structures which might
prove a challenge for compatibility of snapshot files across a range
of bhyve versions. The file format also does not currently support
versioning of individual chunks of state. As a result, the current
file format is not a fixed binary format and future revisions to save
and restore will break binary compatiblity of snapshot files. The
goal is to move to a more flexible format that adds versioning,
etc. and at that point to commit to providing a reasonable level of
compatibility. As a result, the current implementation is not enabled
by default. It can be enabled via the WITH_BHYVE_SNAPSHOT=yes option
for userland builds, and the kernel option BHYVE_SHAPSHOT.
Submitted by: Mihai Tiganus, Flavius Anton, Darius Mihai
Submitted by: Elena Mihailescu, Mihai Carabas, Sergiu Weisz
Relnotes: yes
Sponsored by: University Politehnica of Bucharest
Sponsored by: Matthew Grooms (student scholarships)
Sponsored by: iXsystems
Differential Revision: https://reviews.freebsd.org/D19495
This option was added as a transition aide when symbol versioning was
first added. It was enabled by default in 2007 and is supported even
by the old GPLv2 binutils. Trying to disable it currently fails to
build in libc and at this point it isn't worth fixing the build.
Reported by: Michael Dexter
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D24637
A number of components require OpenSSL and fail to build if it is not
enabled. As a first phase force these off under WITHOUT_OPENSSL. A
second phase should make these more fine-grained, allowing the component
to build but without OpenSSL.
PR: 245931
Sponsored by: The FreeBSD Foundation
instead of MK_KERBEROS. The reason for this change is some users
prefer to build FreeBSD WITHOUT_KERBEROS, wanting to retain the
Kerberos rc scripts to start/stop MIT Kerberos or Heimdal from ports.
PR: 197337
Reported by: Adam McDougall <ebay at looksharp.net>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D24252
According to the upstream man page (which we don't install), none of
libauditd's symbols are intended to be public. Also, I can't find any
evidence for a port that uses libauditd. Therefore, we should treat it like
other such libraries and use PRIVATELIB.
Reported by: phk
Reviewed by: cem, emaste
MFC after: 2 weeks
This change allows any downstream or otherwise consumer to easily override
the new -fno-common default on a temporary basis without having to hack into
src.sys.mk, and also makes it a bit easier to search for these specific
cases where -fno-common must be overridden with -fcommon or else the build
will fail.
The gdb build, the only program requiring -fcommon on head/, is switched
over as an example usage. It will need it on all branches, so this does not
harm future mergability.
MFC after: 3 days
on all major Linux distributions as well as NetBSD and OpenBSD.
Remove the undocumented ZONEINFO_OLD_TIMEZONES_SUPPORT and the deprecated
OLDTIMEZONES knobs as they are now the default.
Reviewed by: ngie, rgrimes
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D24306
-fno-common will become the default in GCC10/LLVM11. Plenty of work has been
put in to make sure our world builds are no -fno-common clean, so let's slap
the build with this until it becomes the compiler default to ensure we don't
regress.
At this time, we will not be enforcing -fno-common on ports builds. I
suspect most ports will be or quickly become -fno-common clean as they're
naturally built against compilers that default to it, so this will hopefully
become a non-issue in due time. The exception to this, which is actually the
status quo, is that kmods built from ports will continue to build with
-fno-common.
As of the time of writing, I intend to also make stable/12 -fno-common
clean. What's been done will be MFC'd to stable/11 if it's easily applicable
and/or not much work to massage it into being functional, but I anticipate
adding -fcommon to stable/11 builds to maintain its ability to be built with
newer compilers for the rest of its lifetime instead of putting in a third
branch's worth of effort.
instead of sprinkling them out over many disjoint files. This is a follow-up
to achieve the same goal in an incomplete rev.348521.
Approved by: imp
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D20520
By using -nobuiltininc and adding the clang builtin headers resource dir
to the end of the compiler header search path, we can still find headers
such as immintrin.h but find the FreeBSD version of stddef.h/stdarg.h/..
first.
This is a workaround until we are able to settle on and complete a plan
to harmonize guard macros with LLVM. We've mostly worked out this on
FreeBSD systems by removing select headers from the installed set of
devel/llvm*, but that isn't a good solution for cross build.
Submitted by: arichardson
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D17002
For head/, this will remain eternally default-on to maintain the status quo.
For stable/ branches, it should be flipped to default-off to maintain the
status quo.
There's value in being able to flip it one way or the other easily on head
or stable branches, whether you want to gain some performance back on head/
(for machines there's little chance you'll actually hit an assertion) or
potentially diagnose a problem with the version of llvm on an older branch.
Currently, stable branches get the CFLAGS+= -ndebug line uncommented; going
forward, they will instead have the default of LLVM_ASSERTIONS flipped.
Reviewed by: dim, emaste, re (gjb)
MFC after: 1 week
MFC note: flip the default of LLVM_ASSERTIONS
Differential Revision: https://reviews.freebsd.org/D24264
If INTERNALLIB is defined we need PIE and bsd.incs.mk is
not included.
PR: 245189
Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org//D24233
This is handy for making local hacks to an app
(eg to build it as tool for non-BSD host)
without making a mess of the code base.
Reviewed by: bdrewery
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org//D24101
In-tree gdb is essentially obsolete. We kept it for sparc64 (because
gdb in ports lacked sparc64 support) and as a fallback for crashinfo.
gdb was installed to /libexec on all archs other than sparc64, where the
WITHOUT_GDB_LIBEXEC option was default, with gdb installed to /usr/bin.
With sparc64's retirement WITH_GDB_LIBEXEC became the default for all
architectures, but it was still possible to set it off and install gdb
into /usr/bin.
As the next step in gdb's retirement, remove the option and install gdb
only into /libexec as the crashinfo fallback. We expect users to install
the gdb port or package for debugging. The in-tree gdb lacks support for
a number of supported architectures and does not support contemporary
DWARF debug info.
Reviewed by: jhb (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24227
Now that LLD 10 is out, and required patches have landed, we are now ready
to finally switch away from the ancient in-tree ld.bfd.
Special thanks to Fangrui Song for many hours of work on getting the
32-bit powerpc lld ready for prime-time.
Reviewed by: emaste (earlier revision), jhibbits
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D24111
Original commit message:
bsd.lib.mk: Do not include bsd.incs.mk for INTERNALLIB
f we're building an internal lib do not bother including bsd.incs.mk so we
will not install the headers.
This also "solves" a problem with pkgbase where a libXXX-development package
is created and due to how packages are created we add a dependency to a
libXXX package that doesn't exists.
If we're building an internal lib do not bother including bsd.incs.mk so we
will not install the headers.
This also "solves" a problem with pkgbase where a libXXX-development package
is created and due to how packages are created we add a dependency to a
libXXX package that doesn't exists.
Reported by: pizzamig
Reviewed by: pizzamig bapt emaste
Differential Revision: https://reviews.freebsd.org/D24166
Having kyua in the base system will simplify automated testing in CI and
eliminates bootstrapping issues on new platforms.
The build of kyua is controlled by WITH(OUT)_TESTS_SUPPORT.
Reviewed by: emaste
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24103
It is added an INTERNALLIB and not installed. It will be used by kyua.
This is a preparatory commit for D24103.
Reviewed by: emaste
Obtained from: CheriBSD
Sponsored by: DARPA
Now that we have updated the in-tree version of LLVM to 10.0, we have all the
necessary LLVM changes to use Clang+LLD as the default toolchain for MIPS.
Relnotes: yes
Reviewed By: emaste, jhb, brooks, kevans
Differential Revision: https://reviews.freebsd.org/D23204
Use TARGET_ARCH and/or MACHINE_ARCH exclusively. Change all __TT uses to __T
with appropriate translations. MACHINE/TARGET is to be used only for kernel
things, and this fixes the last few stragglers.
Use TARGET_ARCH and/or MACHINE_ARCH exclusively. Change all __TT uses to __T
with appropriate translations. MACHINE/TARGET is to be used only for kernel
things.
Delete the conditions that forcibly disabled GOOGLETEST and LLDB for
pre-C++11 C++ compilers, since we no longer support such compilers.
Also delete the complicated method of defaulting LIBCPLUSPLUS to YES.
Prodded by: kevans
Sponsored by: The FreeBSD Foundation
We no longer support older C++ compilers, so do not need to explicitly
test for C++11 support.
After r339946 we stopped running `cc --version` during cleandir/obj
stages, so stopped setting COMPILER_FEATURES. This in turn meant
lib/libomp was excluded from the clean stage in a normal buildworld
(i.e., one without -DNO_CLEAN), and this is what caused recent build
failures with errors about missing ittnotify_static.c.
This commit should obviate the need for the workaround committed in
r359083. Thanks to bdrewery for the insight and for pushing for a
correct fix. There are more cleanups to be done, but this change is
a simplification and an improvement over r359083.
Sponsored by: The FreeBSD Foundation
This allows simplification of Makefiles where some SUBDIR entries depend
on two things (e.g. something that depends on C++ and some other knob).
Discussed with: imp, jhb
Obtained from: CheriBSD
MFC after: 3 days
Sponsored by: DARPA
The new liblua will be used in a forthcoming import of kyua.
Reviewed by: kevans
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24090
The vectx API, computes the hash for verifying a file as it is read.
This avoids the overhead of reading files twice - once to verify, then
again to load.
For doing an install via loader, avoiding the need to rewind
large files is critical.
This API is only used for modules, kernel and mdimage as these are the
biggest files read by the loader.
The reduction in boot time depends on how expensive the I/O is
on any given platform. On a fast VM we see 6% improvement.
For install via loader the first file to be verified is likely to be the
kernel, so some of the prep work (finding manifest etc) done by
verify_file() needs to be factored so it can be reused for
vectx_open().
For missing or unrecognized fingerprint entries, we fail
in vectx_open() unless verifying is disabled.
Otherwise fingerprint check happens in vectx_close() and
since this API is only used for files which must be verified
(VE_MUST) we panic if we get an incorrect hash.
Reviewed by: imp,tsoome
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org//D23827
Summary:
Allow src.conf to override the inferred COMPAT_ARCH and COMPAT_CPUTYPE
variables, such that a different CPU target can be specified explicitly
for the general target vs the compat target.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D23992
Now that we no longer have GCC 4.2.1 in the tree and can assume FreeBSD
is being built with a C++11 compiler available, we can use BSDL dtc
unconditionally and retire the GPL dtc.
GPL dtc now has FreeBSD CI support via Cirrus-CI to help ensure it
continues to build/work on FreeBSD and is available in the ports tree
if needed.
The copy of (copyfree licensed) libfdt that we actually use is in
sys/contrib/libfdt so the extra copy under contrib/dtc/libfdt can be
removed along with the rest of the GPL dtc.
Reviewed by: kevans, ian, imp, manu, theraven
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23192
With the retirement of GCC 4.2.1 we can assume the host compiler supports
C++11, and can simplify the Clang and LLD defaults. Clang and lld are now
enabled by default everywhere, and are used as the bootstrap compiler and
linker for all targets except MIPS.
Sponsored by: The FreeBSD Foundation
LLVM's libunwind is used on all FreeBSD-supported CPU architectures and
is a required component.
Reviewed by: brooks (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23123
As described in Warner's email message[1] to the FreeBSD-arch mailing
list we have reached GCC 4.2.1's retirement date. At this time all
supported architectures either use in-tree Clang, or rely on external
toolchain (i.e., a contemporary GCC version from ports).
GCC 4.2.1 was released July 18, 2007 and was imported into FreeBSD later
that year, in r171825. GCC has served us well, but version 4.2.1 is
obsolete and not used by default on any architecture in FreeBSD. It
does not support modern C and does not support arm64 or RISC-V.
Thanks to everyone responsible for maintaining, updating, and testing
GCC in the FreeBSD base system over the years.
So long, and thanks for all the fish.
[1] https://lists.freebsd.org/pipermail/freebsd-arch/2020-January/019823.html
PR: 228919
Reviewed by: brooks, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23124
Binutils has already been reduced to installing ld only on powerpc32
and as only on amd64. (Also objdump on every arch supported by binutils
2.17.50.) Although BINUTILS_BOOTSTRAP serves no purpose on MIPS there
is no reason to have a special case for it.
Sponsored by: The FreeBSD Foundation
Summary:
With COMPILER_FREEBSD_VERSION, we use a numeric value that we bump each
time we make a change that requires re-bootstrapping, but with the
linker variant, we instead take the entire part after "FreeBSD", as in
this example version output:
LLD 9.0.1 (FreeBSD c1a0a213378a458fbea1a5c77b315c7dce08fd05-1300006) (compatible with GNU linkers)
E.g., LINKER_FREEBSD_VERSION is currently being set to
"c1a0a213378a458fbea1a5c77b315c7dce08fd05-1300006". This means that
*any* new upstream lld version will cause re-bootstrapping.
We should only look at the numerical field we append after a dash
instead. This review attempts to make it so.
The only thing I am not happy about is the post-processing of awk output
in Makefile.inc1. I notice that our awk does not have gensub(), so it
can't substitute a numbered sub-regex with \1, \2, etc. Suggestions
welcome. :)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D23691
Support for NO_CTF, NO_DEBUG_FILES, NO_INSTALLLIB, NO_MAN, NO_PROFILE,
and NO_WARNS as deprecated in 2014 with a warning added for each one
found. Turn these into error in preperation for removal of compatability
support before FreeBSD 13.
This was previously committed in r354909 and reverted in r355011 due to
unforseen impacts on ports. I've since corrected all amd64 and i386
ports reported in prior runs as well as instance of these variables I
found via grep.
As explained in the comment; GOOGLETEST cannot currently be compiled on any
mips variant at the moment due to the cross toolchain seemingly using the
wrong spec and not pulling in libgcc. We'll be fine when llvm 10 lands, at
which point this should be reverted most expeditiously.
libssp_nonshared.a defines one symbol, __stack_chk_fail_local. This
is used only on i386 and powerpc; other archs emit calls directly to
__stack_chk_fail. Simplify linking on other archs by omitting it.
PR: 242941 [exp-run]
simple_httpd was granted a reprieve from the picobsd removal based on having
some reported user; it turns out this user isn't actually using the version
in base and merging their changes would be difficult at this point, so the
version in base will simply continue to rot. Retire it now, it may make a
comeback to ports with the improved version.
No notice issued because its current visibility has only been for ~3
months, and a notice has been previously issued about picobsd removal.
Disable new clang 10.0.0 warnings about misleading indentation in flex.
As this is contributed code with very messy indentation, which will
almost certainly never be upgraded, just disable the warning.
MFC after: 3 days
Work around two -Werror warning issues in googletest, which have been
solved upstream in the mean time.
The first issue is because one of googletest's generated headers contain
classes with a user-declared copy assignment operator, but rely on the
generation by the compiler of an implicit copy constructor, which is now
deprecated:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/internal/gtest-param-util-generated.h:5284:8: error: definition of implicit copy constructor for 'CartesianProductHolder3<testing::internal::ParamGenerator<bool>, testing::internal::ValueArray3<int, int, int>, testing::internal::ValueArray4<cache_mode, cache_mode, cache_mode, cache_mode> >' is deprecated because it has a user-declared copy assignment operator [-Werror,-Wdeprecated-copy]
void operator=(const CartesianProductHolder3& other);
^
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/gtest-param-test.h:1277:10: note: in implicit copy constructor for 'testing::internal::CartesianProductHolder3<testing::internal::ParamGenerator<bool>, testing::internal::ValueArray3<int, int, int>, testing::internal::ValueArray4<cache_mode, cache_mode, cache_mode, cache_mode> >' first required here
return internal::CartesianProductHolder3<Generator1, Generator2, Generator3>(
^
/usr/src/tests/sys/fs/fusefs/io.cc:534:2: note: in instantiation of function template specialization 'testing::Combine<testing::internal::ParamGenerator<bool>, testing::internal::ValueArray3<int, int, int>, testing::internal::ValueArray4<cache_mode, cache_mode, cache_mode, cache_mode> >' requested here
Combine(Bool(), /* async read */
^
For now, silence the warning using -Wno-deprecated-copy.
The second issue is because one of the googlemock test programs attempts
to use "unsigned wchar_t" and "signed wchar_t", which are non-standard
and at best, hazily defined:
contrib/googletest/googlemock/test/gmock-actions_test.cc:111:37: error: 'wchar_t' cannot be signed or unsigned [-Wsigned-unsigned-wchar]
EXPECT_EQ(0U, BuiltInDefaultValue<unsigned wchar_t>::Get());
^
contrib/googletest/googlemock/test/gmock-actions_test.cc:112:36: error: 'wchar_t' cannot be signed or unsigned [-Wsigned-unsigned-wchar]
EXPECT_EQ(0, BuiltInDefaultValue<signed wchar_t>::Get());
^
For now, silence the warning using -Wno-signed-unsigned-wchar.
MFC after: 3 days
solved upstream in the mean time.
The first issue is because one of googletest's generated headers contain
classes with a user-declared copy assignment operator, but rely on the
generation by the compiler of an implicit copy constructor, which is now
deprecated:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/internal/gtest-param-util-generated.h:5284:8: error: definition of implicit copy constructor for 'CartesianProductHolder3<testing::internal::ParamGenerator<bool>, testing::internal::ValueArray3<int, int, int>, testing::internal::ValueArray4<cache_mode, cache_mode, cache_mode, cache_mode> >' is deprecated because it has a user-declared copy assignment operator [-Werror,-Wdeprecated-copy]
void operator=(const CartesianProductHolder3& other);
^
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/gtest-param-test.h:1277:10: note: in implicit copy constructor for 'testing::internal::CartesianProductHolder3<testing::internal::ParamGenerator<bool>, testing::internal::ValueArray3<int, int, int>, testing::internal::ValueArray4<cache_mode, cache_mode, cache_mode, cache_mode> >' first required here
return internal::CartesianProductHolder3<Generator1, Generator2, Generator3>(
^
/usr/src/tests/sys/fs/fusefs/io.cc:534:2: note: in instantiation of function template specialization 'testing::Combine<testing::internal::ParamGenerator<bool>, testing::internal::ValueArray3<int, int, int>, testing::internal::ValueArray4<cache_mode, cache_mode, cache_mode, cache_mode> >' requested here
Combine(Bool(), /* async read */
^
For now, silence the warning using -Wno-deprecated-copy.
The second issue is because one of the googlemock test programs attempts
to use "unsigned wchar_t" and "signed wchar_t", which are non-standard
and at best, hazily defined:
contrib/googletest/googlemock/test/gmock-actions_test.cc:111:37: error: 'wchar_t' cannot be signed or unsigned [-Wsigned-unsigned-wchar]
EXPECT_EQ(0U, BuiltInDefaultValue<unsigned wchar_t>::Get());
^
contrib/googletest/googlemock/test/gmock-actions_test.cc:112:36: error: 'wchar_t' cannot be signed or unsigned [-Wsigned-unsigned-wchar]
EXPECT_EQ(0, BuiltInDefaultValue<signed wchar_t>::Get());
^
For now, silence the warning using -Wno-signed-unsigned-wchar.
MFC after: 3 days
This should fix linker errors when building with clang+lld.
After this change the lib32 compat libraries are now buildt with
-mhard-float instead of -msoft-float
Reviewed By: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D23229
x86 needs bootstrap GNU as for assembling a few files, and powerpc needs
GNU ld.bfd for linking 32-bit objects. All other targets either fully
use in-tree Clang and lld, or rely on external toolchain.
Sponsored by: The FreeBSD Foundation
dma(8) depends on OpenSSL unconditionally.
Reported by: Michael Dexter's Build Options Survey run
MFC after: 1 weeks
Sponsored by: The FreeBSD Foundation
Filemon will add the ability to ignore the cookie if the installed file is
missing. Without filemon that's not possible though so if the cookie is present
an the command unchanged then the install wouldn't run.
Sponsored by: DellEMC
MFC after: 2 weeks
Profiling library archives are part of the development environment; they
don't need to be in separate -profile packages.
(In fact we can probably just eliminate the _p.a archives assuming that
profiling will be done using hwpmc etc., but that is a change for later.)
Discussed with: bapt, manu
Sponsored by: The FreeBSD Foundation
arichardson has an actual fix for the same issue that this was working
around; given that we don't build with llvm today, go ahead and revert the
workaround in advance.
Explicitly setting WITHOUT_KERBEROS implies WITHOUT_KERBEROS_SUPPORT,
but previously other cases that forced KERBEROS off (such as
WITHOUT_CRYPT) did not also set KERBEROS_SUPPORT off. Because the
_SUPPORT dependent options (KERBEROS/KERBEROS_SUPPORT) are processed
before other dependencies (CRYPT/KERBEROS) it's not easy to make this
happen automatically. Instead just explicitly set KERBEROS_SUPPORT
off where we set KERBEROS off.
Reported by: Michael Dexter's Build Option Survey run
hard use floating point hardware, pass registers to functions in
floating point registers.
softfp use floating point hardware, but pass registers to functions
in integer registers.
soft do floating point calcuations without using floating point
hardware. Pass arguments in integer registers.
FreeBSD 11 and newer assumes hard. 10 and earlier assumed softfp. We have no
real support, at the moment, for soft. It's untested, though, if softfp still
works.
Add a note here since this is a whack-a-doodle combination relative to all other
platforms.
softfp is likely to go away in the future because it was retained for people
using FreeBSD 10 + armv6 needing to transition more slowly from softfp -> hard
than the project. It likely is no longer needed, and may be getting in the
way of people needing 'soft' support.
Only sparc64 did not enable LLVM_LIBUNWIND. After r356513 LLVM_LIBUNWIND
should at least build on sparc64. The old DWARF unwinder will be removed
along with GCC 4.2.1 in the near future, so switch sparc64 to use LLVM's
unwinder in advance of the removal. Someone with access to the obsolete
sparc64 hardware supported by FreeBSD will have to test, and investigate
any failures. I will gladly help, but I don't have any suitable hardware
myself.
PR: 233405
bsd.cpu.mk is included by bsd.init.mk before bsd.linker.mk, so it
was always setting the flag since LINKER_FEATURES wasn't defined.
Reported by: mhorne
Reviewed by: imp, mhorne
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23076
- Enable clang and lld as system toolchains.
- Don't use external GCC for universe by default.
- Re-enable riscv64sf since it builds fine with clang + lld.
Reviewed by: emaste, mhorne
Relnotes: yes
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23089
This re-enables building the googletest suite by default on mips and instead
specifically doesn't build fusefs tests for mips+clang builds. clang will
easily spent >= 1.5 hours compiling a single file due to a bug in
optimization (see LLVM PR 43263), so turn these off for now while that's
hashed out.
GCC builds are unaffected and build the fusefs tests as-is. Clang builds
only happen by early adopters attempting to hash out the remaining issues.
The comment has been updated to reflect its new position and use less strong
wording about imposing on people.
Discussed with: ngie, asomers
Reviewed by: ngie
Extend r356379 to include 32-bit mips and sparc64. Using a decade-old
binutils linker with a contemporary compiler (either Clang or GCC) is
a combination unlikely to be used by anyone else, and it's not going
to be a good use of our time investigating and addressing any issues
that arise. Expect that all architectures newly migrated to external
GCC will also use external binutils.
After GCC was disabled by default in r356367, mips and sparc64 started
relying external GCC. However, the in-tree Binutils ld 2.17.50 is not
compatible with GCC for some mips64 targets, so turn off
BINUTILS_BOOTSTRAP and rely on external binutils (linker) as well.
For libssp.so, rebuild stack_protector.c with FORTIFY_SOURCE stubs that just
abort built into it.
For libssp_nonshared.a, steal stack_protector_compat.c from
^/lib/libc/secure and massage it to maintain that __stack_chk_fail_local
is a hidden symbol.
libssp is now built unconditionally regardless of {WITH,WITHOUT}_SSP in the
build environment, and the gcclibs version has been disconnected from the
build in favor of this one.
PR: 242950 (exp-run)
Reviewed by: kib, emaste, pfg, Oliver Pinter (earlier version)
Also discussed with: kan
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D22943
Use "mipsel" instead of "mips" as the 32-bit MACHINE_ARCH when
building lib32 for little-endian 64-bit MIPS targets. This fixes an
error where some objects were compiled as LE and others compiled as BE
causing a link error for rtld32.
Reviewed by: emaste
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23028
