| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Don't do upgrade_checks when using bmake. As long as we have WITH_BMAKE,
there's a bootstrap complication in ths respect. Avoid it. Make the
necessary changes to have upgrade_checks work wth bmake anyway.
2. Remove the use of -E. It's not needed in our build because we use ?= for
the respective variables, which means that we'll take the environment
value (if any) anyway.
3. Properly declare phony targets as phony as bmake is a lot smarter (and
thus agressive) about build avoidance.
4. Make sure CLEANFILES is complete and use it on .NOPATH. bmake is a lot
smarter about build avoidance and should not find files we generate in
the source tree. We should not have files in the repository we want to
generate, but this is an easier way to cross this hurdle.
5. Have behavior under bmake the same as it is under make with respect to
halting when sub-commands fail. Add "set -e" to compound commands so
that bmake is informed when sub-commands fail.
6. Make sure crunchgen uses the same make as the rest of the build. This
is important when the make utility isn't called make (but bmake for
example).
7. While here, add support for using MAKEOBJDIR to set the object tree
location. It's the second alternative bmake looks for when determining
the actual object directory (= .OBJDIR).
Submitted by: Simon Gerraty <sjg@juniper.net>
Submitted by: John Van Horne <jvanhorne@juniper.net>
|
|
|
|
|
|
| |
as there are warnings.
Reviewed by: nwhitehorn
|
|
|
|
|
|
|
|
|
|
| |
internal knowledge that "cd" is a shell's built-in. Such makes
may attempt to exec() "cd" that in turn will fail on systems that
lack the "cd" executable.
Reworked this by eliminating the root cause.
Submitted by: Simon Gerraty <sjg@juniper.net>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r238211:
Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb
This adds a new TARGET_ARCH for building on ARM
processors that support the ARMv6K multiprocessor
extensions. In particular, these processors have
better support for TLS and mutex operations.
This mostly touches a lot of Makefiles to extend
existing patterns for inferring CPUARCH from ARCH.
It also configures:
* GCC to default to arm1176jz-s
* GCC to predefine __FreeBSD_ARCH_armv6__
* gas to default to ARM_ARCH_V6K
* uname -p to return 'armv6'
* make so that MACHINE_ARCH defaults to 'armv6'
It also changes a number of headers to use
the compiler __ARM_ARCH_XXX__ macros to configure
processor-specific support routines.
Submitted by: Tim Kientzle <kientzle@freebsd.org>
|
|
|
|
| |
it belongs.
|
|
|
|
| |
it belongs.
|
|
|
|
| |
Submitted by: Simon Gerraty <sjg@juniper.net>
|
|
|
|
| |
relocations.
|
|
|
|
|
|
|
|
|
| |
"gnusort". Most of the BSD sort development work was done by
Oleg Moskalenko <oleg.moskalenko@citrix.com>.
- GNU grep can be set to default by setting WITH_GNU_GREP. It will cause
BSD sort to be installed as "bsdsort".
Portbuild tested by: linimon
|
| |
|
|
|
|
|
|
| |
"bsdsort" and GNU sort will be the default "sort". When WITH_BSD_SORT
is set, BSD sort will be the default "sort" and GNU sort will be installed
as "gnusort".
|
|
|
|
|
|
| |
PR: 167696
Submitted by: Nobuyuki Koganemaru (kogane!jp.freebsd.org)
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
toolchain binaries as dynamically linked. Option is disabled by
default.
Reviewed by: ru (previous version)
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes our naming scheme more closely match other systems and the
expectations of much third-party software. MIPS builds which are little-endian
should require and exhibit no changes. Big-endian TARGET_ARCHes must be
changed:
From: To:
mipseb mips
mipsn32eb mipsn32
mips64eb mips64
An entry has been added to UPDATING and some foot-shooting protection (complete
with warnings which should become errors in the near future) to the top-level
base system Makefile.
|
|
|
|
|
| |
This change makes object files compiled with default flags by
gcc and as compatible.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
installs clang as /usr/bin/cc, /usr/bin/c++ and /usr/bin/cpp.
Note this does *not* disable building and installing gcc, which will
still be available as /usr/bin/gcc, /usr/bin/g++ and /usr/bin/gcpp. If
you want to disable gcc completely, you must use WITHOUT_GCC.
MFC after: 2 weeks
|
|
|
|
| |
Reviewed by: cognet
|
|
|
|
| |
MFC after: 1 month
|
|
|
|
|
| |
Including this header file causes a compilation warning. The code builds
perfectly fine without this header file.
|
|
|
|
|
| |
Sponsored by: Adara Networks, Inc.
MFC after: 3 days
|
|
|
|
|
|
| |
unused input() functions emitted by lex.
MFC after: 1 week
|
| |
|
|
|
|
|
| |
Reviewed by: cognet
Approved by: cognet
|
| |
|
|
|
|
|
| |
we can also use the upstream binutils linker where we have to have a unique
name for the FreeBSD emulation.
|
|
|
|
|
|
| |
(It is "well known" that GCC 4.2.2 is GPLv3.)
* Don't give the impression that this compiler isn't "trustable".
* Fix dependency nit.
|
| |
|
|
|
|
|
|
|
|
| |
- change "the the" to "the"
Approved by: lstewart
Approved by: sahil (mentor)
MFC after: 3 days
|
|
|
|
|
|
| |
it from the 9.0-RELEASE release cycle code freeze.
Approved by: re (implicit)
|
|
|
|
|
|
|
| |
used anyway, and it breaks the build, since sys/ptrace.h now includes
<machine/reg.h>
Approved by: re
|
|
|
|
|
|
|
|
|
| |
and processes in a kernel image. This allows examination of threads that
have exited or are in the late stages of exiting.
Tested by: avg
Approved by: re (kib)
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
kgdb(1).
Reviewed by: marcel
Approved by: re (kib)
MFC after: 1 week
|
|
|
|
| |
Reviewed by: jilles, gjb
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This also replaces the local fix in r219209 that made .Ac emit
ASCII angle quotes with an official fix. In the official fix,
ASCII quotes are output when using the .Aq, .Ao and .Ac calls,
but only when nested into the .An macro.
PR: gnu/154822
|
|
|
|
| |
correct.
|
|
|
|
|
|
| |
rets.
Requested by: kib
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
If WITH_BSD_GREP is not set, it will be 'bsdgrep' and GNUgrep will be
'[ef]grep'. Otherwise, BSD-grep will be the grep family, and GNUgrep
will be 'gnugrep'.
Discussed with: brooks
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| | |
over building gcc and binutils. They default to true, unless
MK_TOOLCHAIN is no.
Reviewed by: ru@
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some files keep the SUN4V tags as a code reference, for the future,
if any rewamped sun4v support wants to be added again.
Reviewed by: marius
Tested by: sbruno
Approved by: re
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cpuset_t objects.
That is going to offer the underlying support for a simple bump of
MAXCPU and then support for number of cpus > 32 (as it is today).
Right now, cpumask_t is an int, 32 bits on all our supported architecture.
cpumask_t on the other side is implemented as an array of longs, and
easilly extendible by definition.
The architectures touched by this commit are the following:
- amd64
- i386
- pc98
- arm
- ia64
- XEN
while the others are still missing.
Userland is believed to be fully converted with the changes contained
here.
Some technical notes:
- This commit may be considered an ABI nop for all the architectures
different from amd64 and ia64 (and sparc64 in the future)
- per-cpu members, which are now converted to cpuset_t, needs to be
accessed avoiding migration, because the size of cpuset_t should be
considered unknown
- size of cpuset_t objects is different from kernel and userland (this is
primirally done in order to leave some more space in userland to cope
with KBI extensions). If you need to access kernel cpuset_t from the
userland please refer to example in this patch on how to do that
correctly (kgdb may be a good source, for example).
- Support for other architectures is going to be added soon
- Only MAXCPU for amd64 is bumped now
The patch has been tested by sbruno and Nicholas Esborn on opteron
4 x 12 pack CPUs. More testing on big SMP is expected to came soon.
pluknet tested the patch with his 8-ways on both amd64 and i386.
Tested by: pluknet, sbruno, gianni, Nicholas Esborn
Reviewed by: jeff, jhb, sbruno
|
| |
|