Subject: Re: m68000 new toolchain issues
To: Todd Vierling <>
From: Matthew Fredette <fredette@MIT.EDU>
List: tech-toolchain
Date: 12/10/2001 09:58:58
> 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?



Matt Fredette