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>
Add a LOCAL_LIB_DIRS variable to complement the existing LOCAL_DIRS
and LOCAL_TOOL_DIRS variables. Directories in LOCAL_LIB_DIRS are
built at the end of the _generic_libs target.
Reviewed by: imp (212854)
stages (build-tools, cross-tools, etc) of the build, so we can detect in
bsd.*.mk whether to pass compiler-specific flags to ${CC}.
In particular, this commit will allow using WITH_CLANG_IS_CC when the
base compiler is still gcc, and when ${CC}, ${CXX} and ${CPP} are left
at their defaults. The early stages will then be built using gcc, and
no clang-specific flags will be passed to it. The later stages will be
built as usual.
The EARLY_BUILD define can also serve other uses, such as building the
world stage C++ executables with libc++ instead of libstdc++: during the
early build stages, we cannot assume libc++ is already available, so we
must still build with libstdc++ at that time.
MFC after: 1 week
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.
several new kerberos related libraries and applications to FreeBSD:
o kgetcred(1) allows one to manually get a ticket for a particular service.
o kf(1) securily forwards ticket to another host through an authenticated
and encrypted stream.
o kcc(1) is an umbrella program around klist(1), kswitch(1), kgetcred(1)
and other user kerberos operations. klist and kswitch are just symlinks
to kcc(1) now.
o kswitch(1) allows you to easily switch between kerberos credentials if
you're running KCM.
o hxtool(1) is a certificate management tool to use with PKINIT.
o string2key(1) maps a password into key.
o kdigest(8) is a userland tool to access the KDC's digest interface.
o kimpersonate(8) creates a "fake" ticket for a service.
We also now install manpages for some lirbaries that were not installed
before, libheimntlm and libhx509.
- The new HEIMDAL version no longer supports Kerberos 4. All users are
recommended to switch to Kerberos 5.
- Weak ciphers are now disabled by default. To enable DES support (used
by telnet(8)), use "allow_weak_crypto" option in krb5.conf.
- libtelnet, pam_ksu and pam_krb5 are now compiled with error on warnings
disabled due to the function they use (krb5_get_err_text(3)) being
deprecated. I plan to work on this next.
- Heimdal's KDC now require sqlite to operate. We use the bundled version
and install it as libheimsqlite. If some other FreeBSD components will
require it in the future we can rename it to libbsdsqlite and use for these
components as well.
- This is not a latest Heimdal version, the new one was released while I was
working on the update. I will update it to 1.5.2 soon, as it fixes some
important bugs and security issues.
the cross-tools stage, if CC=clang and WITH_CLANG_IS_CC is not set.
This causes no 'cc' to be installed in the temporary cross-tools tree,
making lint fall over later in the build, because it ignores ${CC} and
attempts to run 'cc' anyway.
To fix this, only skip building gcc during cross-tools, if WITHOUT_GCC
is set, or if WITH_CLANG_IS_CC is set.
Pointy hat to: dim
MFC after: 2 weeks
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
to the default from the top-level Makefile. Therefore, invocations of
lex and yacc (used during building of aicasm) will use the executables
in /usr/bin, not those optionally built during the previous buildworld
or kernel-toolchain. This makes kernel builds from older FreeBSD
releases more difficult than necessary.
Fix this by setting PATH to ${BPATH}:${PATH} in stage 2.3, so the
bootstrap tools directories are searched before the regular ones.
Silence from: svn-src-{all,head}
MFC after: 1 week
kernels specified by KERNCONF are built and packed into release.
The first one is packed into kernel.txz, all others to
kernel.CONFIG.txz.
The first one is installed on bootables in /boot.
Things such as "sh" require local tools to be built before
cross-compiling. This allows for extra software (that's
built via LOCAL_DIRS) to also have a build-tools target where
required.
for our gcc since more than three years (see r181534, which is also in
stable/9 and stable/8). This flag used to be for the benefit of the old
in-kernel math emulator, which was removed more than eight years ago.
Pointed out by: arundel
MFC after: 1 week
defined based on WITH/WITHOUT_CTF settings, default is WITHOUT_CTF,
NO_CTF overrides WITH_CTF (used by Makefile.inc1)
- CTFCONVERT_CMD/NORMAL_CTFCONVERT are now defined to empty string
if make(1) can handle empty commands
not disabled in the usual way (by adding it to __DEFAULT_NO_OPTIONS in
share/mk/bsd.own.mk), and because the test for MK_LIBCPLUSPLUS in
Makefile.inc1 was incorrect.
Pointy hat to: dim
MK_LIBCPLUSPLUS=yes to enable). This is a work-in-progress. It works for
me, but is not guaranteed to work for anyone else and may eat your dog.
To build C++ using libc++, add -stdlib=libc++ to your CXX and LD flags.
Bug reports welcome, bug fixes even more welcome...
Approved by: dim (mentor)
doesn't have ${WORLDTMP}/usr/bin in its PATH, if you build world with
CC=clang, tblgen tools from /usr/bin will be used instead of the ones
built under ${WORLDTMP}. This can lead to various errors, especially if
you upgrade from an older clang.
Note that building world with gcc would not experience these problems,
because it only uses the tblgen tools in the world stage, where PATH
does contain ${WORLDTMP}/usr/bin.
Pointy hat to: dim
bootstrap-tools stage to the cross-tools stage. These tools are only
needed for generating llvm/clang include files, and are not necessary
for bootstrapping the build itself.
This shaves off some build time, because the required libraries are now
just built twice (during the cross-tools and world stages), instead of
three times.
Also, if you build world using WITHOUT_CLANG= in src.conf(5), no llvm or
clang code will be compiled at all anymore.
MFC after: 1 week
make.conf(5), while allowing the build32 stage on 64-bit architectures
to still override them, so that stage can successfully build 32-bit
compatibility libraries.
Explanation:
1) The build32 stage sets environment variables CC, CXX, AS and LD for
its sub-make, to add 32-bit specific flags (-m32 and such).
2) The sub-make reads sys.mk, encounters CC?= and CXX?= assignments, so
does not alter them.
3) After some other stuff, sys.mk reads /etc/make.conf. When you have
"CC=xxx" and "CXX=yyy" statements in there, they will *override* the
build32-supplied CC/CXX values, nullifying the 32-bit specific flags.
4) Thus all objects get built as 64-bit anyway, and since LD is usually
not set in make.conf, it still has the 32-bit flags!
5) Now, whenever something is linked, you will get a "ld: Relocatable
linking with relocations from format elf64-x86-64-freebsd (foo.o) to
format elf32-i386-freebsd (bar.o) is not supported" error.
Fix this by adding "-ECC -ECXX -EAS -ELD" to the build32 sub-make
invocation, which forces those environment variables to always override
any assignment in makefiles. Thus making it possible to simply set:
CC=my-cc
CXX=my-c++
in your make.conf, or specify a path, even:
CC=/usr/local/bin/other-cc
CXX=/usr/local/bin/other-c++
Note this was never a problem on i386, since it has no build32 stage.
Silence from: current@
MFC after: 1 week
There are two problems with the existing logic. It builds gensnmptree
on <700018, even if WITHOUT_BSNMP is set, but more importantly, we must
not forget to build gensnmptree on systems that have originally been
built without. This causes a buildworld on those systems to fail.
MFC after: 1 week
digit beyond your time.
Various sysinstall dependencies (e.g. libftpio, libdisk, libodialog, etc.)
will be cleaned up in coming days. Some will take longer than others due to
a few other consumers (tzsetup and sade).
kerberos libraries were not linked properly (missing dependencies),
which causes 3rd party applications linking to fail when --as-needed
ld flag is used. I also added the --no-undefined ld(1) flag to make
sure that there're no missing dependencies.
MFC after: 3 days
doc/, and now www/ trees, but only using the "cvsup" transport.
When "make update" is run using a tree's makefile, it can also use
"cvs" (except for www/) and "svn" (only src/).
Clean up documentation and code regarding "make update":
- Increase oddness by adding support for WWWSUPFILE and NO_WWWUPDATE to
Makefile.inc1 (analogous to PORTSSUPFILE/NO_PORTSUPDATE and
DOCSUPFILE/NO_DOCUPDATE; WWWSUPFILE already supported by www/Makefile).
- Document all trees that support CVS_UPDATE.
- Document all trees that support SUP_UPDATE.
- Document SVN_UPDATE.
- Document NO_WWWUPDATE.
- make.conf(5) mistakenly said that *SUPFILE* had defaults.
- Add an example entry for WWWSUPFILE.
one. Without this, we don't have ar or randlib in the tool path,
leading to much pain for some users. This pain is exposed by the
external toolchain enhancements that I'm working on.
Submitted by: John Hein (ages ago, and dropped on the floor by me: sorry)
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
