The preferred way to modify the object directory root is to use OBJROOT.
However, setting OBJROOT to ${MAKEOBJDIRPREFIX}/${SRCTOP}/ effectively behaves
as expected.
The problem with this before was that setting OBJROOT to contain SRCTOP
resulted in a recursive replacement (/usr/obj/usr/obj/usr/src/). Anchoring to
the start of the path for replacing SRCCTOP in CURDIR resolves this by
avoiding replacing SRCTOP when CURDIR is within the OBJDIR.
Sponsored by: EMC / Isilon Storage Division
This would lead to the 2nd build (after the first with a missing OBJROOT) to
always rebuild everything as the 'command' would have changed due to the path
changing from having // to only /.
Sponsored by: EMC / Isilon Storage Division
MAKEOBJDIR is based on OBJTOP so cannot be expanded until OBJTOP is set.
Reported by: Nikolai Lifanov <lifanov@mail.lifanov.com>
Sponsored by: EMC / Isilon Storage Division
If MAKEOBJDIRPREFIX is set, use it for default OBJROOT.
If MAKEOBJDIR is empty or not a suitable value (no '/')
set a default that works.
Reviewed by: bdrewery
Go ahead and defined -D_STANDALONE for all targets (only strictly
needed for some architecture, but harmless on those it isn't required
for). Also add -msoft-float to all architectures uniformly rather
that higgley piggley like it is today.
Differential Revision: https://reviews.freebsd.org/D3496
remove duplicates. We cannot sort SUBDIR because many Makefiles
have .WAIT in the list which is strongly ordering. Rather than
try to second guess when to sort and when to not sort depending
on .WAIT being in the list, just remove duplicates.
armv6. It's too ambiguous. We do use the softfp ABI for the moment on
armv6, but we allow floating point register use (and the compilers
will generate it). This is too ambiguous to use it as a decider for
which algorithms to use on the platform. Err on the side of caution
and not define it.
Submitted by: ian@
Reviewed by: andrew@
float targets. It is added for booke on powerpc and all arm with hf in
the string. Also add arm to all arm builds and armv6 to armv6 and
newer builds.
PR: 202641
For most cases they are equivalent, but BINUTILS_BOOTSTRAP is a
BROKEN_OPTION on arm64 as the in-tree GNU binutils do not support it,
so we need a separate internal flag for ELF Tool Chain.
Reviewed by: andrew, brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3381
As the name indicates, these are flags to pass to nm(1). The newer
binutils have a plugin mechanism so, to build something with LLVM's
LTO, we need to pass flags to nm(1). This commit also extends
lorder(1) to pass NMFLAGS to nm(1).
Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock. If the thread does not otherwise use SSE,
this usage incurs a context-switch of the FPU/SSE state, which
reduces the performance of multiple real-world applications by a
non-trivial amount (3-5% in one application).
Instead of this change, I experimented with eagerly switching the
FPU state at context-switch time. This did not help. Most of the
cost seems to be in the read/write of memory--as kib@ stated--and
not in the #NM handling. I tested on machines with and without
XSAVEOPT.
One counter-argument to this change is that most applications already
use SIMD, and the number of applications and amount of SIMD usage
are only increasing. This is absolutely true. I agree that--in
general and in principle--this change is in the wrong direction.
However, there are applications that do not use enough SSE to offset
the extra context-switch cost. SSE does not provide a clear benefit
in the current libthr code with the current compiler, but it does
provide a clear loss in some cases. Therefore, disabling SSE in
libthr is a non-loss for most, and a gain for some.
I refrained from disabling SSE in libc--as was suggested--because
I can't make the above argument for libc. It provides a wide variety
of code; each case should be analyzed separately.
https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055193.html
Suggestions from: dim, jmg, rpaulo
Approved by: kib (mentor)
MFC after: 2 weeks
Sponsored by: Dell Inc.
We previously disabled CLANG_FULL on (little-endian) ARM because the
build failed. This is no longer the case and as of Clang 3.5 we cannot
build any part of the in-tree Clang with in-tree GCC, so it's no longer
necessary to disable CLANG_FULL.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2525
ELF Tool Chain elfcopy is nearly a drop-in replacement for GNU objcopy,
but does not currently support PE output which is needed for building
x86 UEFI bits.
Add a src.conf knob to allow installing it as objcopy and set it by
default for aarch64 only, where we don't have a native binutils.
Reviewed by: bapt
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2887
Allow Makefiles to define generic metadata settings that apply to all test
programs defined by a Makefile. The generic TEST_METADATA variable extends
the per-test program settings already supported via TEST_METADATA.<program>.
This feature will be useful to easily apply some settings to all programs
in a directory. In particular, Kyua 0.12 will support parallel execution
of test programs and a bunch of them will need to be tagged as is_exclusive
to indicate that they cannot be run in parallel with anything else due to
their side-effects. It will be reasonable to set this setting on whole
directories.
MFC after: 1 week
This makes sysroot usable for cross building, it also removes the need for
_SHLIBDIRPREFIX (keeps its definition since picobsd uses it and I have no time
to test it)
Differential Revision: https://reviews.freebsd.org/D2920
Submitted by: imp, adrian
Tested by: adrian
This means moving include of local.sys.mk and src.sys.mk too.
Introduce new includes to take the early slot, for the purpose
of being able to influence toolchains and the like.
Differential Revision: D2860
Reviewed by: imp
really need it can find it in the devel/fmake port or pkg install fmake.
Note: This commit is orthogonal to the question 'can we fmake buildworld'.
Differential Revision: https://reviews.freebsd.org/D2840
