Dan Albert
Dan Albert
Nothing's changed since our last update.
I don't think this is written down anywhere, and it might be useful for people trying to figure out what to do in their apps, so here's basically my view...
> Is c++_headeronly a potential option? Just wouldn't do any linking - so presumably would give linker errors if the user actually needs to choose between c++_shared and c++_static? I'm...
Yeah, I'm convinced. I think it's okay for us to skip the "we're changing the default next release" past and just so that in r18. I'm considering just removing it...
The other thing we'll need to decide is whether we maintain the support for new/delete, exceptions, and RTTI when STL is none. I'm inclined to opt for no, especially since...
We've settled on libc++_shared as a new default for ndk-build, and I'm hoping to bring CMake in line with that (only thing that will prevent it is if that will...
I think the best option for us is to punt this out to r19 so we can give the gradle folks time to prepare for the change.
Fixing gradle for this is something we probably need to do ourselves, and I haven't found the time yet, so moving to r20.
> Basically, with system, I can at have the same environment as C++ code in AOSP. AOSP uses libc++. > @arturbac I would think so to, but in my case...
I don't really feel all that strongly about keeping support for libstdc++ around. The one part I would like to drop is the support for the system STL with exception/RTTI...