Change Details

As the removed comment says, definitions of new/delete are normally provided in libc++, so it doesn't make sense to provide them in libc++abi unless requested explicitly. It appears the only thing preventing us from switching the default to OFF was GCC 4.9, which we don't support anymore. Vendors wishing to keep shipping new/delete in libc++abi can do so by asking for it explicitly when building libc++abi.

As the removed comment says, definitions of new/delete are normally provided in libc++, so it doesn't make sense to provide them in libc++abi unless requested explicitly. The only thing preventing us from switching the default to OFF was thought to be GCC 4.9, but in reality it's that the linker used by GCC on Linux doesn't resolve references to new/delete from libc++abi to the definitions in libc++. Re-linking libc++ after libc++abi in the tests for libc++abi does the trick. Furthermore, this only changes the default behavior of libc++abi: vendors wishing to ship new/delete in libc++abi can do so by asking for it explicitly when building libc++abi

As the removed comment says, definitions of new/delete are normally provided in libc++, so it doesn't make sense to provide them in in libc++abi unless requested explicitly. It appears theThe only thing preventing us from switching the default to to OFF was thought to be GCC 4.9, which we don't support anymorebut in reality it's that the linker used by GCC on Linux doesn't resolve references to new/delete from libc++abi to the definitions in libc++. Vendors wishing to keep shippingRe-linking libc++ after libc++abi in the tests for libc++abi does the trick. Furthermore, this only changes the default behavior of libc++abi: vendors wishing to ship new/delete in libc++abi can do so by asking for it it explicitly when building libc++abi.