I've been able to cross compile (on linux 1686) an almost complete
netbsd tree and kernel using USE_NEW_TOOLCHAIN. I had to turn off
MKKERBEROS, and MKPIC, and I didn't build the in-tree gcc, or binutils
(though they will build with minor fixes).

There were a very few things which now seem to assume the existance
of machine/elf_machdep.h, which fail for the pc532 port.

I used current gcc and binutils (from the FSF development, not the
in-tree ones). I made minor changes to binutils and gcc. The gcc fix
should be back-portable to earlier versions OK.

A prefunctory check shows most utilities work and the kernel works.
There are few minor changes required due to the new ld interpreting
the text base address options slightly differently.

The only failure I know of is "groff" which coredumps. I am assuming
this is something todo with binutils, weak symbols and groff being in
implimented in c++, but apart from that, I don't have much of a clue.

The good news is that I did not have a single internal compiler error
doing all that. Correction, I did have *one* compiling "boot" with
-O3. Turning back the optimisation to -O2 or adding -fno-rename-registers
eliminated that one. So, I regard the "reload" problems as fixed.

Issues from here on:

o  I wanted to try the in-tree toolchain gas and ld. It seems that the
   other ports use configuration files generated by "toolchain2netbsd"
   and that script has been removed from the cvs repository. How are you
   meant to {re}generate these files?

o  ELF is still not available for this port. Can we not assume ELF for a bit
   longer, even in the case of USE_NEW_TOOLCHAIN/ I think we should go to
   ELF for this port, but in the interim, it would be helpful.

o  I certainly intend to submit patches to the gcc people and the binutils
   people. Is that sufficient or should they go in parallel somewhere to
   make sure they get in the netbsd tree? Bear in mind that they have not
   been made against, or tested with, the versions in the netbsd tree.

Ian