On Thu, Nov 06, 2014 at 09:36:52AM +0000, David Chisnall wrote:
> On 6 Nov 2014, at 01:04, Rui Paulo <[email protected]> wrote:
> 
> > I don't think the non-temporary fix was ever committed.  What's the 
> > problem?  Is something else defining these methods?
> 
> Yes, they're defined by libc++ too.  The problem is that gcc 4.9 wants to be 
> able to throw bad_array_new_length exceptions when you do new foo[x] and 
> sizeof(foo) * x overflows.  It does this by calling a support function 
> defined in the C++ runtime, but that means that the C++ runtime must have the 
> bad_array_new_length class defined there too.  Having the methods on those 
> classes defined in libcxxrt and libc++ breaks things.
> 
> The correct fix was to move a #endif in libc++ so that it didn't compile 
> those functions.  There was some discussion about whether we needed to 
> support the case that old libc++ and new libcxxrt were used, but it's 
> probably not required.  Bapt was going to check whether there were any symbol 
> versioning issues with code compiled against old libc++/libcxxrt and 
> dynamically linked against the new one.  

I will backout this change since it is not necessary anymore as well as upstream
the missing parts of the bad_array_new_lenght exception in libcxxrt in the next
couple of days.

regards,
Bapt

Attachment: pgphq3DXsxm_N.pgp
Description: PGP signature

Reply via email to