[PATCH] Fix building statically linked ARM EABI applications (fwd)

[Joseph S. Myers]

On Thu, 1 Oct 2009, Hans-Peter Nilsson wrote:

> I suggested the patch, because it doesn't seem that it would
> break anything, at least nothing that wasn't already broken.  I
> mean, if a signal is thrown from within uclibc and the exception
> table in sigrestorer.S was to be used (mind you, signals can be
> translated into exceptions for some targets, apparently
> including ARM) and __aeabi_unwind_cpp_pr1 is actually needed,
> then stubbing it in the shared uclibc by aeabi_unwind_cpp_pr1.c
> is the wrong thing.  For all other uses, -lc normally is

It may be that the non-stub versions are only needed for code where 
exceptions may be caught, or which has cleanups to be run during 
unwinding, rather than code that is just thrown through.  Certainly NPTL 
has such code (with cleanups) in glibc at least, so you wouldn't want a 
dummy version used there.

> included only *after* -lgcc -lgcc_eh/-lgcc_s so those functions
> wouldn't be picked even in the static library - unless you hack
> your gcc invocation to leave out -lgcc_eh or the equivalent, in
> which case TRT happens.

Normally (i.e. when you don't use -nostdlib), either the -lgcc options are 
present on both sides of -lc or --start-group --end-group are used around 
the -lgcc options and -lc.  See LINK_GCC_C_SEQUENCE_SPEC.

-- 
Joseph S. Myers
joseph at codesourcery.com