http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #24 from Iain Sandoe <iains at gcc dot gnu.org> 2013-01-23 13:33:15 UTC --- (In reply to comment #23) > (In reply to comment #21) > > ... I don't have darwin11 or 12 (yet) - but should do soon. > > The test also fails on darwin10 unless the patch in comment #7 is applied. indeed it does (with xcode 3.2.6) and passes on x86-Darwin9 OK - so a recap; weak linking works just fine on Darwin - with the semantics that Darwin defines (where references are provided at link time, but may be missing at run time). Some versions of Darwin's tool chain components and dynamic linker also support ELF-style weak linking semantics. However, in this case, the references *are* present on the link line (lstdc++) but also a duplicate in crttme.o --- So, in this case (at least on x86-darwin10), I am not yet sure exactly where the problem lies. 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. 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. [on Darwin10] If I manually remove the crttme.o from the link line, the testcase executes OK. Time is v. short at the moment - prob won't have a chance to investigate further for a couple of weeks.
