> This is deliberate; there is no need to create libgcc.a in the *compiler's*
> directory, because it will never get used.  All builds with the new
> toolchain have DESTDIR set, which means that -nostdlib (and an absolute path
> to ${DESTDIR}/usr/lib/libgcc.a) will be used.  (This avoids the
> chicken-and-egg problem that you found where libgcc2.c wants to get at the
> native target headers.)
> 
> What needs to work properly for you is src/gnu/lib/libgcc, since that's the
> only libgcc that will be used for a build.

Got it, thanks.

Also, binutils makes CPU32 executables with an e_machine value of EM_68K 
but with an e_flags value of EF_CPU32 (defined in include/elf/m68k.h),
which is just the kind of CPU identifying I need for the m68000.  In my 
working directory I picked another value for a new EF_M68000 flag; with 
what authority should we register/clear/whatever a new flag value?

Thanks,

Matt

--
Matt Fredette
http://mit.edu/fredette/www