Some users build FreeBSD as non-root in Perforce workspaces. By default,
Perforce sets files read-only unless they're explicitly being edited.
As a result, the -f argument must be used to cp in order to override the
read-only flag when copying source files to object directories. Bare use of
'cp' should be avoided in the future.
Update all current users of 'cp' in the src tree.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: Spectra Logic
because they pollute the POSIX environment, which doens't allow
for these extentions. ctf conversions are really only relevant when
used in coordination with the rest of the bsd*.mk system anyway.
Leave them in place for the normal, non-posix enviornment since
they are quite useful there.
all timestamps in static libraries to 0 so that consecutive builds
from the same source, even on different machines, produce identical
libraries.
MFC after: 3 weeks
This targets the existing ARMv6 and ARMv7 SoCs that contain a VFP unit.
This is an optional coprocessors may not be present in all devices, however
it appears to be in all current SoCs we support.
armv6hf targets the VFP variant of the ARM EABI and our copy of gcc is too
old to support this. Because of this there are a number of WITH/WITHOUT
options that are unsupported and must be left as the default value. The
options and their required value are:
* WITH_ARM_EABI
* WITHOUT_GCC
* WITHOUT_GNUCXX
In addition, without an external toolchain, the following need to be left
as their default:
* WITH_CLANG
* WITH_CLANG_IS_CC
As there is a different method of passing float and double values to
functions the ABI is incompatible with existing armv6 binaries. To use
this a full rebuild of world is required. Because no floating point values
are passed into the kernel an armv6 kernel with VFP enabled will work with
an armv6hf userland and vice versa.
But we don't want to set it to + for bmake since it breaks make -N
which is used to supress the normal handling of targets marked with .MAKE
(which seems broken in fmake and might be why _+_ was introduced).
Add some comments to explain what's gong on.
Reviewed by: obrien
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>
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>
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.
- CTFCONVERT_CMD=... is a hack (should be defined to empty string instead):
make(1) should be taught to ignore empty commands silently in compat mode
(as it does in !compat mode, GNU make also silently ignores empty commands)
and to skip printing empty commands in !compat mode
- config(8) should generate ${NORMAL_CTFCONVERT} invocation without '@':
this will allow to simplify kern.pre.mk even more and lessen the number
of shell invocations during kernel build when CTF is turned off
- WITH_CTF can now be converted to usual MK_CTF=yes/no infrastructure
Pointy hat to: fjoe [1]
Implement MACHINE_ARCH=mips64e[lb] to build N64 images. This replaces
MACHINE_ARCH=mipse[lb] TARGET_ABI=n64.
MACHINE_ARCH=mipsn32e[lb] has been added, but currently requires
WITHOUT_CDDL due to atomic issues in libzfs. I've not investigated
this much, but implemented this to preserve as much of the TARGET_ABI
functionality that I could. Since its presence doesn't affect the
working cases, I've kept it in for now.
Added mips64e[lb] to make universe, so more kernels build.
And I think this (finally) closes the curtain on the tbemd tree.
run. This makes the 'ctfconvert' and 'ctfmerge' programs show up during
a build when compiling a kernel, a library or a program.
Sponsored by: The FreeBSD Foundation
Introduce MACHINE_CPUARCH. Many different MACHINE_ARCHs will be built
from one MACHINE_CPUARCH. This will allow us to move to a more
standard MACHINE_ARCH for mips and arm which exist in many different
endian variants, and for powerpc where both 32 and 64 bit binaries are
generated from the same sources.
Reviewed by: arch@ (mostly silence though)
are some problems with static executables), make.conf (would also
affect ports which do not use GNU make and do not override the
compile targets) or in the kernel config (via "makeoptions
WITH_CTF=yes").
Additional (related) changes:
- propagate WITH_CTF to module builds
- do not add -g to the linker flags, it's a noop there anyway
(at least according to the man page of ld)
- do not add -g to CFLAGS unconditionally
we need to have a look if it is really needed (IMO not) or if there
is a way to add it only when WITH_CTF is used
Note: ctfconvert / ctfmerge lines will not appear in the build output,
to protect the innocent (those which do not build with WITH_CTF would
see the shell-test and may think WITH_CTF is used).
Reviewed by: imp, jhb, scottl (earlier version)
Discussed on: arch@
system makefiles.
Note that the CTF conversion defaults to off. We may choose to change this
default later if DTrace proves popular and people are prepared to wear
the compilation performance impact of compiling with debug symbols all the
time.
Setting NO_CTF in the make args or user environment turns off CTF conversion.
Even if we choose to default CTF generation to on later, we still need
NO_CTF so that the buildworld process can bootstrap the tools without
needlessly generating CTF data for temporary tools.
Setting WITH_CTF in the make args or user environment (and _NOT_ in
/etc/make.conf) is the only way to enable CTF data conversion. Nore that
this can't be implemented the same way that the WITH_ and WITHOUT_ stuff
is implemented throughout the buildworld because the CTF conversion needs
to work when building a simple object without a Makefile, using the
default rules in sys.mk.
Typing 'make test.o' with no makefile and just a source file test.c
should work. Also, typing 'make WITH_CTF=1 test.o without a makefile and
just a source file test.c should work and produce an object with a CTF
elf section. Typing 'make WITH_CTF=1 CFLAGS=-g test.o' without a makefile
and just a source file test.c should produce an object with both a CTF
elf section and the debug elf sections.
In the FreeBSD build where more .mk files are used than just sys.mk
which is included my make by default, the use of DEBUG_FLAGS is the
correct way to enable a debug build. The important thing to note here
is that it is the DEBUG_FLAGS setting that prevents libraries and
programs from being stripped on installation. So, for the addition of
CTF data conversion, setting DEBUG_FLAGS to contain -g, without NO_CTF,
will cause the ctfconvert and ctfmerge build programs to be executed
also with the -g arg so that debug symbols are retained rather than
being removed after the CTF data elf section has been added.
Add DTrace libraries to the list of libnames.
o Default to -O on mips as well as arm. -O2 has been strongly implicated
in many problems in the past, so we're taking a conservative approach
until the problems are well understood.
to JB's revision 1.96 change to remove -fno-strict-aliasing from CFLAGS.
This makes the default CFLAGS to match the simple defaults that the
tinderboxes use. By using -fno-strict-aliasing by default we are
choosing to ignore problems in code which had the potential to
shoot ourselves in the foot.
address PR ports/121363 (current day re-opening of PR ports/73797)
to make ports CFLAGS more independent of src/'s CFLAGS WRT aliasing.
Discussed with: brooks
Change the default CFLAGS to match the simple defaults that the
tinderboxes use. By using -fno-strict-aliasing by default we are
choosing to ignore problems in code which had the potential to
shoot ourselves in the foot.
in the default CFLAGS, we're in the middle of a ports freeze, so we can't
really go making the corresponding change to the ports mk files.
I'll take -fno-strict-aliasing out again when the ports freeze ends.
This time, change the default CFLAGS to match the simple defaults that
the tinderboxes use. That is, don't use -fno-strict-aliasing by default.
My last attempt to re-anable -Werror gave me a lesson in what strict
aliasing is all about. There was code in libthr that wasn't 64-bit clean.
The default use of -fno-strict-aliasing hid that.
By using -fno-strict-aliasing by default we were choosing to ignore
problems in code which had the potential to shoot ourselves in the
foot. Sometimes it would be the 64-bit foot. I have both feet. The left
ones are 32 bits and the right ones are 64 bits. Don't ask about my
endian orientation. :-)
The -fno-strict-aliasing compiler arg can still be used if NO_STRING_ALIASING
is define in make.
We are early in the FreeBSD 8 development, so we have the opportunity to
wait and see if this works for us. I am sure that people will complain.
We can easily revert this. All I ask is that we take sides: clean code or
not. YMMV.
Note that by using -fno-strict-aliasing the build won't actually break.
Only where WARNS is set (and -Werror is used) will a compiler warning break
the build. The use of WARNS levels implies (to me at least) that the
developer has taken some care to make the code pass basic checks. This
commit makes those checks just a little bit more strict.
__MAKE_SHELL variable. This feature isn't supposed to be in wide
use, but it's needed now to make `installworld' independent of the
stock binaries and libs so that radical ABI changes can go in safely.
Reviewed by: ru
"There seems to be some continuing discussion about how this is best fixed,
and we'd like to get Alexander (as our gcc guru) to opine on a final
solution before picking one. In the mean time, could you back out the
original commit (sys.mk:1.89)?"
Approved by: re (rwatson)
default. Grepping through src shows only gnu/usr.bin/groff which doesn't
use it in src build and OpenSSH for which this was a NOOP.
Discussed with: des, ru
Approved by: ru
(getting zillions of warnings). Building an old release uses that release's
sys.mk which does not switch on these warnings, so make will be silent.
They can be switch on on the command line with the -x option to make.
This has been tested by building RELENG_5_4 on CURRENT.
by adding WANT_IPFILTER to /etc/make.conf. Note that this is only a partial
hack and only works when building the world and kernel the 'sanctioned' way.
I hope that this hack is only temporary and can be reverted soon.
given -n. For POLA reasons this behaviour is switched on only when
at least two -n flags are given to make. One -n flag keeps the old behaviour
of showing the shell command that would recurse into the sub-directories.
Discussed with: ru
existence of this file. This stopped working more than 4 years ago when
the generation of the error was added in rev.1.44. The .error directive
gives fatal errors, so stale /etc/make.conf.local files must have been
gone away more than 4 years on systems where make(1) works.
CFLAGS in all cases, but POSIX requires a default of -O. Adding
-pipe unconditionally still is still broken for non-gcc compilers
in the non-POSIX case.
libraries to be reported as up-to-date.
Before:
# make -f /dev/null nonexistent.a
`nonexistent.a' is up to date.
After:
# make -f /dev/null nonexistent.a
make: don't know how to make nonexistent.a. Stop
PR: bin/44137 (part of)
to creating the tags file using ctags(1). Defaults to "gtags".
Made GTAGSFLAGS and HTAGSFLAGS overrideable, added CTAGSFLAGS.
Folded bsd.prog.mk version of `tags' into bsd.dep.mk.
PR: bin/42852
o Make it possible to prevent parts of the tree from being linted
(say) during a 'make world' by setting NOLINT in a leaf Makefile.
o Make "make lint" work (better) for executable programs.
o Clean up (nuke!) a syntax damaged pipeline.
under way to move the remnants of the a.out toolchain to ports. As the
comment in src/Makefile said, this stuff is deprecated and one should not
expect this to remain beyond 4.0-REL. It has already lasted WAY beyond
that.
Notable exceptions:
gcc - I have not touched the a.out generation stuff there.
ldd/ldconfig - still have some code to interface with a.out rtld.
old as/ld/etc - I have not removed these yet, pending their move to ports.
some includes - necessary for ldd/ldconfig for now.
Tested on: i386 (extensively), alpha
to use ``.if defined()'' inside bsd.own.mk to test for defines
in individual makefiles. For example, setting DEBUG_FLAGS in
Makefile didn't take the desired effect on the STRIP assignment.
Added bsd.init.mk (like in NetBSD) that handles the inclusion
of ../Makefile.inc and bsd.own.mk from all bsd.*.mk files that
"build something".
Back out bsd.own.mk,v 1.15: moved OBJFORMAT initialization back
to sys.mk (several source tree makefiles want to check it early)
and removed MACHINE_ARCH initialization (it's hard to see from
looking at the commitlogs what the problem was at the time, but
now it serves no purpose).
Prohibit the direct inclusion of bsd.man.mk and bsd.libnames.mk.
Protect bsd.obj.mk from repetitive inclusion. Prohibiting the
direct inclusion of bsd.obj.mk might be a good idea too.
(See commit log for usr.bin/xlint/Makefile,v 1.11 for what was wrong
with enabling build of lint libraries in rev. 1.12.)
This fixes cross-arch compiles (running binaries for a different arch
when generating lint.7 and lint libraries) and cross-branch compiles
(4.x -> 5.0 buildworld should be working again).
Use this where we are now using /etc/make.conf.
This allows people to override the current default of always including
/etc/make.conf. Setting __MAKE_CONF to /dev/null disables it
completely, while setting it to something else allows one to override
what is on the system. This can be desirable in situations where a
machine has many users and some of them want different defaults, or
defaults appropriate to cross building to be different than those for
normal building.
Not objected to by: arch@
lint, so this is turned off by default. Setting WANT_LINT will turn
on generation of lint libraries for /usr/libdata/lint/*.ln.
Reviewd by: silence in -audit.
supposed to be edited by the user and didn't define important things,
thus we can just skip it (that's where it differs from the make.conf.local
change).
Submitted by: ru
discussed on the arch@ mailinglist (after repo-copy).
sys.mk will .error if it finds /etc/defaults/make.conf but include
it anyways (this is the same behaviour as with the make.conf.local
removal).
/usr/share/examples/etc/make.conf has BDEFLAGS commented out now,
since it's only an example file.
Adjust all textes that talk about make.conf or defaults/make.conf to
match the new situation.
(While there, I also moved the single suffix C rules beside the double
suffix ones so they are easier to find)
PR: 24438
Submitted by: Georg-W. Koltermann <gwk@sgi.com>
* Rip out MACHINE_CPU stuff from sys.mk and include a new <bsd.cpu.mk>
after we pull in /etc/make.conf. We need to do it afterwards so we can
react to the user setting of the:
* CPUTYPE variable, which contains the CPU type which the user wants to
optimize for. For example, if you want your binaries to only run on an
i686-class machine (or higher), set this to i686. If you want to support
running binaries on a variety of CPU generations, set this to the lowest
common denominator. Supported values are listed in make.conf.
* bsd.cpu.mk does the expansion of CPUTYPE into MACHINE_CPU using the
(hopefully) correct unordered list of CPU types which should be used on
that CPU. For example, an AMD k6 CPU wants any of the following:
k6 k5 i586 i486 i386
This is still an unordered list so the client makefile logic is simple -
client makefiles need to test for the various elements of the set in
decreasing order of priority using ${MACHINE_CPU:M<foo>}, as before.
The various MACHINE_CPU lists are believed to be correct, but should be
checked.
* If NO_CPU_CFLAGS is not defined, add relevant gcc compiler optimization
settings by default (e.g. -karch=k6 for CPUTYPE=k6, etc). Release
builders and developers of third-party software need to make sure not to
enable CPU-specific optimization when generating code intended to be
portable. We probably need to move to an /etc/world.conf to allow the
optimization stuff to be applied separately to world/kernel and external
compilations, but it's not any worse a problem than it was before.
* Add coverage for the ia64/itanium MACHINE_ARCH/CPUTYPE.
* Add CPUTYPE support for all of the CPU types supported by FreeBSD and gcc
(only i386, alpha and ia64 first, since those are the minimally-working
ports. Other architecture porters, please feel free to add the relevant
gunk for your platform).
Reviewed by: jhb, obrien
set the variable until you rebuild it, and the alternative is to be stuck
playing games with ``.if defined(MACHINE_CPU) && ... '' for all eternity.
We now set up the reasonable default for i386 and alpha here -- given this
it probably makes sense to remove the corresponding code from make(1).
through the use of a new build directive, MACHINE_CPU, which contains a
list of the CPU generations/features for which optimizations are desired.
This feature will be extended to cover the ports tree in the future.
Currently OpenSSL provides optimizations for i386, i586 and i686-class
CPUs. Currently it has not been tested on an i386 or i486.
Teach make(1) to provide sensible defaults for MACHINE_CPU if it is not
defined (namely, the lowest common denominator CPU we support for each
architecture). Currently this is i386 for the i386 architecture and ev4
for the alpha. sys.mk also sets the variable as a last resort for
consistency with MACHINE_ARCH and bootstrapping from very old versions of
make.
Benchmarks show a significant speed increase even in the i386 case, with
additional improvements for i586 and i686 systems. For maximum performance
define MACHINE_CPU=i686 i586 i386 in /etc/make.conf.
Based on a patch submitted by: Mike Silbersack <silby@silby.com>
Reviewed by: current
