New libgcc_eh dependency for ARM_EABI targets

[Kevin Cernekee]

Commit 4916fd88 (present in v0.9.32, but not in v0.9.32-rc3) created a
new dependency on libgcc_eh.a for the final link stage:

uClibc-0.9.32/libubacktrace/Makefile.in:

ifeq ($(CONFIG_ARM_EABI),y)
LIBGCC += $(shell $(CC) -print-file-name=libgcc_eh.a)
endif

I build gcc stage 1 with --disable-shared, which causes libgcc_eh.a
not to be built:

gcc-4.5.2/libgcc/Makefile.in:

ifeq ($(enable_shared),yes)
all: libgcc_eh.a libgcc_s$(SHLIB_EXT)
...

Therefore, I am not able to build uClibc 0.9.32 with my gcc stage 1
compiler.  This worked fine on uClibc 0.9.32-rc3.

I see that Rob Landley has patched his gcc source tree so that it
always builds libgcc_eh.a.  Is this the recommended procedure going
forward?

Rob:

> I'm building stock gcc 4.2.1 with binutils 2.17 (last GPLv2 release of
> each, I await either LLVM or PCC maturing to usability with bated
> breath).  I am applying a few patches but none of them are sparc
> stuff.  (Half of them fix various issues with arm, one makes
> libgcc_eh.a build during the --disable- shared pass, and the rest fix
> OBVIOUS breakage with sh4, alpha, and mips64 of the "how did they ever
> use those targets" variety).