reasons for this, quite a few of them technical, and not all of them
in response to Intel's broken ia32e crud. The gcc toolchain stays at
x86_64 for now.
we build perl itself. We need perl to run Configure *after* the
other libraries are installed, since Configure looks at what symbols
exist in libc and the other libs. If anfd when other things in the tree
link against libperl we may need to revisit this issue.
- add cross-obj, cross-depend, cross-clean and cross-cleandir targets
- add dependencies between the cross-tools targets
- simplify cross-binutils
- build a cross c++ compiler
- use distribution-etc-root-var in etc for preparing ${CROSSDIR}
ok art@, miod@
cross tools and kernels with those cross tools on all archs except mvme88k
and hppa.
1. Pass MACHINE_ARCH, not MACHINE to TARGET_MACHINE_ARCH when building old
binutils.
2. Instead of using the "intelligent" cpp voodoo to find out MACHINE_ARCH
from MACHINE (which has never worked correctly for sparc, 68k and
recently it broke for powerpc), we have a table of machine->machine_arch
translations. It's easier to modify one table once per arch instead of
juggling for a few hours every time some include files change.
3. Remove some sparc64 cruft.
4. Set MACHINE and MACHINE_ARCH in cross-env, otherwise the kernel will
try to build libkern for the host.
Please note that this doesn't allow you to do complete builds. I haven't
even tested cross-lib. Only kernel builds have been tested.
need to be set for cross building:
cd /usr/src/sbin/init
make `cd /usr/src ; make TARGET=sparc64 cross-env`
Also, xcpp was wrong, cccp is wrong, cpp is probably better.
We simply make sure that there always is a TARGET_CANON-X and an X
regardless of which one is the regular file and which one is the symlink.
(this is for cross-tools)
- remove extra subshells;
- use exec on terminal commands, avoiding dangling shells that don't
control anything.
More correct:
- use && some more;
- remove `-' in front of includes, so that failures WILL fail...
Okay millert@, deraadt@
