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.
${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.
dist .y and .c files reversed.
1. Move the .y.c and other assorted implicit rule overrides out of Makefile.inc
and into local Makefile's. The system Makefile (bsd.sys.mk) sets up .l.c and
.y.c rules so unless these come after all inclusions they just get ignored.
2. Add @true as the command for any of the rule overrides. Otherwise make
still bails complaining about not knowing how to build the requisite .c or
.h file.
This obviously wasn't tested before as it couldn't have worked as-is.
changes to configuration stuff to (a) recognize `mipseb', and (b) build a
BE-default GCC on mipseb. gprof and gdb still not done.
WARNING: Binutils 2.11.2 (maybe earlier) changed the MIPS ABI, so any
shared libs built by this toolchain WILL NOT WORK without either a whack
to BFD to fix that or a patch to ld_elf.so to work around it. I need to
chase the binutils folks on this issue still.
That said, the new toolchain seems to work quite well once the ABI change
is worked around/fixed -- I'm committing from a machine running a user-
land built with the new compiler.
build in the middle and restarting on another platform (requiring atomic
host tool builds), and keep parallelism, the ".lo" rules can't be used
at all. Instead, compile all host .c files directly into executables.
lukem