[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693

--- Comment #34 from Iain Sandoe <iains at gcc dot gnu.org> 2013-01-23 20:35:47 UTC ---

(In reply to comment #24)

> However, in this case, the references *are* present on the link line (lstdc++)
> but also a duplicate in crttme.o

> since -lstdc++ is on the link line (ahead of crttme.o) - I would expect darwin
> to resolve the  __cxa__ symbols from the shared library.  It is not doing so -
> and I (or someone) need(s) to re-check the priority of satisfying linkage.  

$ nm -mapv /usr/lib/libstdc++.6.dylib |grep __cxa_allo
000452e8 (__TEXT,__text) external ___cxa_allocate_exception

$ nm -mapv /GCC/gcc-live-trunk-build/i686-apple-darwin9/libgcc/crttme.o |grep
__cxa_allo
00000100 (__TEXT,__textcoal_nt) weak external ___cxa_allocate_exception

In fact, since the libstdc++ symbols is NOT weak, and the crttme.o is ...

... ISTR non-weak should override weak - but need to re-RTFM.

if that is the case, one is tempted to speculate that this might be a ld64 bug.

> It might be that naming the crt as a .o forces it to be processed ahead of the
> shared lib.  In which case, perhaps we can modify our crttme to be an arch
> containing that single object.

I have a work-around hack in test.