address parts of PR toolchain/14896. This header file is nonstandard
(and doesn't even exist in gcc 3.0); an out-of-the-box gcc build also
doesn't provide the missing functions. So just drop the .h completely.
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.
for files named .cc or .C. _eh gets generated into a .c file so we need
explicit rules for it's targets (.o .po and .so) to compile it correctly.
Without this exceptions just plain don't work. Nothing ever gets caught.
...And while we're at it, add a profiled libgcc too.
Use the "generate .c files and let <bsd.lib.mk> sort it out" method
for compiling these libraries. Only one real divergence (-fexceptions)
existed, but exceptions are turned on for C++ code by default in gcc
2.95.3, so this option was redundant anyway.
From Rafal's commit for mipseb (which applies here too):
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.
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.
gcc 3.0 build (as noted by mrg), bump shlib major again, to version 4.0.
There might be a better solution to this kind of thing in the future; I'll
have to think about it.
