On 16 Mar 2015 at 20:13, Dmitry Moskalchuk wrote:
I'll also add some of my own experiences as I formalised the port of Thread to Android, plus AFIO v1.3 is now regularly CI tested on Android. Firstly, the STL default configured by the Android NDK is woefully defective, however the good news is that the recent NDKs can be asked to use libc++ and that's a very recent edition of libc++, so you get excellent C++ 14 STL support.
libc++ - it's LLVM libc++ from LLVM upstream with Google's modifications. In contrast with GNU libstdc++, it implemented even worse. It doesn't test features available on target platform on build stage, so Google's guys modified it much more than they did in GNU libstdc++. Unfortunately, all modifications lead to "get it built", not to "get it working". Thus, it's in "experimental" state in Google's NDK, and very unstable, crashing very frequently on real usage. Again, this happens because of bad Android libc implementation.
Ok, I did overegg the pudding. I really should have said "In my limited experience from Thread and AFIO, the libc++ STL is the least worst STL in the standard Android NDK". And I agree most of where the problems stem from is Google's poor quality libc. However I found that AFIO works well with libc++ on Android, and it is passing all unit tests quite nicely, and it didn't require much effort from me to make that happen. I had no chance with the other STLs as they're too outdated and AFIO is C++ 11 only.
My suggestion to the community is to try and target as a minimum 100% green for Android 5.0 only with the libc++ STL only. Maintainers may choose to exceed that of course. If you target that one single target and keep it all green, that makes the life of CrystaX much easier because effectively speaking what he's done is port newer STLs etc to the older API versions, so really all you need to maintain is the occasional #ifdef __ANDROID__ to work around Android's weird libc and library config and in theory at least, it ought to be good from there.
Of course, this is choice of library maintainers. However, my personal opinion is that would be better to fix underlying layer (what we do in CrystaX NDK) than fixing Boost code itself.
I think we all agree that it is Google who is at fault here. They need to attach a STL expert to their Android NDK team for a year or two. This crappy C++ support makes a lot of hassle for anyone trying to use C++ on Android, and moreover this has been a big problem for *years* now. You really shouldn't have had to start CrystaX at all.
My suggestion to the community is to try and target as a minimum 100% green for Android 5.0 only with the libc++ STL only.
Supporting Android 5.0 is not enough practically.
Please don't take it as aggressive style - I'm trying to avoid it but English is not my native language so it could look so. I'm just
Where I was going with that suggestion is that ALL Boost libraries support Android 5.0 with libc++ STL only. In other words, it becomes an officially recommended target. That support ought to enormously ease your job in getting perfectly working ports for each API version because that config is the closest to the CrystaX one. Each library maintainer can of course choose to go further than just the base NDK. trying
to explain why we started CrystaX NDK and why (IMHO) it's better choice than Google's one for Boost-on-Android.
I'm also coming from the perspective that Google need pressure to up their game. Personally speaking, I think they should write you an annual cheque for $50k and ship CrystaX as their official NDK. But I also recognise that someone's career in Google will suffer/resource problems/face saving/not on radar blah blah. We need to get Google from where they are now to where Microsoft is now. Microsoft's compiler teams can make a very strong business case to their management for investment X, Y and Z because of A, B and C major libraries not working on their compiler. Microsoft then allocates resources, and all our lives improve in not having to head bash against MSVC as badly as before. We need to instil a similar routine at Google. I'm sure the NDK teams would just love more resources to fix the C++ support, and I'm sure their management has decided it isn't worth the cost benefit. We need to tilt that analysis to make it worth the cost benefit. One step to achieve that could be supporting only the very latest and greatest NDK release in Boost with a big fat statement about it being too much maintenance effort to go further (hint hint!). That same technique is used by countless C++ libraries to encourage MSVC to improve. I'm thinking it might work here too. The reason we shouldn't support CrystaX and not the Google NDK is because it makes it harder for the NDK team to pitch to their management because their management will view CrystaX as not the NDK, and therefore irrelevant. I'm all for CrystaX support by the way. Just not without some support for the official Google NDK. Besides, as I mentioned I suspect if it supports Android 5.0 + libc++, the effort involved in making it work on CrystaX is probably trivial. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/