This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]