anything includes <fnmatch.h>. Using our native /usr/include/fnmatch.h is
no good idea, they are incompatible.
XXX - why is tar using it's own implementation?
I'm not sure this is the right way to handle the problem, but it made
a "make cleandir && make" here possible again.
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.
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).
make -V FILES
from being useful (and given that every other variable can be
extracted using make -V, the behaviour was unusually inconsistent
given that the original reason for clearing it doesn't seem to be
relevant anymore)
- use <bsd.prog.mk> instead of directly including <bsd.files.mk>
(and possibly <bsd.man.mk> or <bsd.own.mk>)
- remove obsolete NOPROG
${GNU_ARCH_MACHINE}-netbsd. This allows platforms to that were
formerly a.out but ELF to be foo--netbsdelf. It also adds the
missing 2nd "-" which was missing in the former definition.
`long'. This gives rise to defining `off_t' to a signed 64 bit on LP64
machines giving rise to cross compiling errors.
By explicitly setting it to int32_t its forced to use signed 32 bits
integers as required and expected on the ILP32 ARM processor.
This aparently fixes PR 15303
case:
MKBFD If set to "no", disables building of libbfd, libiberty,
and all things that depend on them (binutils/gas/ld, gdb,
dbsym, mdsetimage).
MKGDB If set to "no", disables bulding of gdb.
MKGCC If set to "no", disables building of gcc and the
gcc-related libraries (libg2c, libgcc, libobjc, libstdc++).
These are useful for building platforms for which either of the following
situations are true:
(1) You have no userland from which to run toolchain2netbsd
in order to build the appropriate toolchain build framework.
(2) The platform which you are building requires a newer set
of tools than are currently in the tree (e.g. x86-64, ia64).
* Regen files with proper OS names and version numbers.
* Clean up toolchain2netbsd somewhat, to get it ready to be cross-host
compatible (more work to be done here, but it's getting closer).
* Add framework for gdbreplay and gdbserver, but hold off on enabling these
by default until low-nbsd.c is verified to work everywhere.
the target "native toolchain" if BOOTSTRAP_NEW_TOOLCHAIN is set.
This is important if you don't have any userland at all, and you're
trying to make one from which you can run toolchain2netbsd.