two variables:
TOOLCHAIN_MISSING -- set to "yes" on platforms for which there is
no working in-tree toolchain (hppa, ns32k, sh5, x86_64).
EXTERNAL_TOOLCHAIN -- if defined by the user, points to the root of
an external toolchain (e.g. /usr/local/gnu). This enables the cross-build
framework even for TOOLCHAIN_MISSING platforms.
If TOOLCHAIN_MISSING is set to "yes", MKGDB, MKBFD, and MKGCC are all
unconditionally set to "no", since the bits are not there to build.
If EXTERNAL_TOOLCHAIN is set, MKGCC is unconditionally set to "no",
since the external toolchain's compiler is not in-sync with the
in-tree compiler support components (e.g. libgcc).
* Set MACHINE_CPU much earlier in bsd.own.mk, so that more tests in
that file can use it.
recurse into submaps (a kernel thing) as suggested by Chuck Cranor,
with the output from these entries indented. Clean up and rework code
slightly, to make the recursion task much easier. Also, add a note to
the BUGS section in the man page thats mentions that stuff "just won't
work right" unless pmap is reading from the proper kernel.
pulled in by <sys/types.h>, and on a non-NetBSD system (host tool case),
it doesn't really matter (since it's just for the __RCSID macro).
There are larger problems with mkmagic's host tool-ness. A PR has been
filed.
C99 support.
- turn lerror() into a macro so that the filename and the line number of the
error are printed before we abort.
- recurse in type printing to provide the proper type name.
We only enable 8-bit output for known single-byte locales, currently
ISO8859-*. For all other locales the program output is unchanged.
RFC-1288 recommends that administrators have a mechanism to enable
characters greater than ASCII 126. A suggested solution is an
environment variable. The environment variables of choice here are
LC_CTYPE and LANG.
Thanks to Martin Husemann <martin@duskware.de> for the idea on checking
for known single-byte locales, to Johan Danielsson <joda@pdc.kth.se> for
checking RFC-1288, and to Jun-ichiro itojun Hagino <itojun@iijlab.net>
for insisting on retaining security for multi-byte locales.
If you experience any problems with these changes, please send me email
describing the problem and how to repeat it. I'd rather try to fix the
problem than have this change reverted. Thanks!
be changed in the future to "yes".
If MKDYNAMICROOT == "no", there is no change from existing behaviour
of a static /bin and /sbin (and a few programs in elsewhere).
If MKDYNAMICROOT == "yes", the following changes occur:
in <bsd.own.mk>:
SHLIBDIR?= /lib
SHLINKDIR?= /lib
in various Makefiles, the following entry is DISABLED.
LDSTATIC?=-static
This results in all programs (except those "standalone" programs built
in sys/arch/*/stand) are linked dynamically, the shared linker is moved
from /usr/libexec to /lib (with a compat symlink), and the shared
libraries used by /bin and /sbin programs are moved from /usr/lib to
/lib (with compat symlinks).
daemon is a bad idea, (2) there's no standard in 8bit finger, (3) there's no
guarantee that finger/fingerd uses the same locale, (4) existing finger client
could scream. see tech-userlevel.
valid for output. If something bad gets printed, either the locale
settings for the user (or output terminal) are wrong, or the LC_CTYPE
definitions on the system are invalid.
valid for output. If something bad gets printed, either the locale
settings for the user (or output terminal) are wrong, or the LC_CTYPE
definitions on the system are invalid.
display disk transfer values (Suggested by Simon Burge). Also clip
%busy to 100 and display as an int which has the useful side effect
of stopping it overflowing into the next column (100.0).
