> From: Iain Sandoe <develo...@sandoe-acoustics.co.uk>
> Date: Mon, 21 Nov 2011 11:04:18 +0100
> On 21 Nov 2011, at 09:34, Hans-Peter Nilsson wrote:
>
> >> From: Paolo Bonzini <bonz...@gnu.org>
> >> Sender: Paolo Bonzini <paolo.bonz...@gmail.com>
> >> Date: Mon, 21 Nov 2011 10:20:39 +0100
> >
> >> H-P, can you try bootstrapping your patch on cygwin and/or mingw too
> >> before applying it?
> >
> > Sorry, I don't have that. Dave?
>
> The reason it was in libgcc_eh (AFAIK, the original implementation pre-
> dates my GCC days) - is because there can only be one copy of the
> static emutls locking entities in a given exe. I guess it was felt
> analogous to the "only one unwinder" rule.
>
> note also: Darwin links libgcc.a even when using dynamic libs - it
> provides eprintf (and the out-of-line GPR/FPR save routines for
> powerpc).
>
> (this is not a total show-stopper, we could provide those things some
> other way)
I'm not sure how, and as I only intended to fix what seemed like
an obvious oversight, I'm just going to fix what's obvious: the
lack of an explanatory comment to warn future similar cleanup
attempts. Don't forget I at one point had an "ok" while no
committer remembered what was the reason! If you have something
better than what's below, that'd be welcome. If you were to fix
the LIB2ADDEH-abuse, that'd be welcome too, but maybe that's not
proper stage-3-material. ;-)
* Makefile.in ($(srcdir)/emutls.c): Explain why it's in
LIB2ADDEH et al.
Index: Makefile.in
===================================================================
--- Makefile.in (revision 181531)
+++ Makefile.in (working copy)
@@ -394,6 +394,9 @@ endif
LIB2ADD += enable-execute-stack.c
+# While emutls.c has nothing to do with EH, it is in LIB2ADDEH*
+# instead of LIB2ADD because that's the way to be sure on some targets
+# (e.g. *-*-darwin*) only one copy of it is linked.
LIB2ADDEH += $(srcdir)/emutls.c
LIB2ADDEHSTATIC += $(srcdir)/emutls.c
LIB2ADDEHSHARED += $(srcdir)/emutls.c
brgds, H-P
