Subject: Re: [boost] Boost on Android
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-16 14:42:38
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.
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.
> 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
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/