Re: [boost] Boost on Android

Subject: Re: [boost] Boost on Android
From: Dmitry Moskalchuk (dm_at_[hidden])
Date: 2015-03-16 13:13:58

> Not to diminish the fine work that CrystaX does, but I want to 
> emphasise to the community that the CrystaX NDK != the Android NDK. 
> Configuring build support specific to the  Android NDK is 
> straightforward if not well documented: if necessary to your Jamfile 
> you add config for target-os=android as this is a cross compilation 
> scenario. Similarly, when building Boost to target Android you pass 
> target-os=android to b2.

Yes, building Boost libraries with Google's Android NDK is
straightforward, but just build libraries is not enough; it's good to
have them _work_, not just _build_. Some Boost libraries are working
good being built with Google's NDK, some not. And this is main
difference between CrystaX NDK and Google's Android NDK - we're going to
make _all_ Boost libraries work on Android, and the only way to do that
is to use own NDK, because it impossible to do with Google's one. I'll
describe it more detailed below.

> 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.

To be more specific: Google's Android NDK offer several implementations
of C++ Standard Library - system (default), stlport, gnustl, libc++ (I'm
naming them here as they are named in Google's NDK). Default one
(system) is not actually real implementation - it only contains
implementation of operator new; nothing more.

stlport - well known STL implementation working on multiple platforms.
However, it's a) not full C++ Standard Library implementation and b) it
doesn't support C++11/C++14.

gnustl - it's GNU libstdc++ from GCC upstream with Google's
modifications. Even though it is GCC's implementation of C++ Standard
Library, don't expect good C++ support from it - mainly because of
defective Android libc implementation. On build stage, GNU libstdc++
configure scripts detect many things supported on target platform and,
since many of them are not supported on Android, many C++ Standard
Library features are become disabled. For example, you will not get
std::stol, std::stoul etc - they are just not available in Google's
gnustl. So it's not full implementation too. Another problem is
std::chrono::monotonic_clock - do you know it's actually
std::chrono::system_clock? I.e. you will not get any compiler/linker
error - it just will not work properly. There are huge number of such
problems, and all of them caused by defective Android libc implementation.

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.

Now, what we did in CrystaX NDK to solve those problems. We have
implemented big part of libc required by C standard in additional
library libcrystax.so, which is added transparently to the link process
_before_ Android libc, thus getting overridden buggy and non-implemented
functions from Android libc. We've also significantly modified sysroot
headers, making them much more POSIX-conforming than original.

That allowed us to make GNU libstdc++ implementation _full_. We've paid
special attention to that, fixing all things it expected from libc but
not detecting on target platform. So using CrystaX NDK you'll get
_actually_ full C++ Standard Library implementation, not _nominally_, as
it is in Google's NDK. BTW, we've made this library 'default' in CrystaX
NDK instead of defective 'system'.

Second, we throw away Google's modifications of LLVM libc++ and using
upstream LLVM libc++ with slight modifications, allowing use it with
gcc, not only with clang. Again, this made it _much_ more stable, since
we touched it minimally, preferring to fix underlying layer to fulfill
standards rather than fixing LLVM libc++ itself.

So developers have choice which C++ Standard Library implementation to
use in CrystaX NDK - GNU libstdc++ or LLVM libc++. We offer both, and
both working better than in Google's NDK.

> 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. Mainly because it will
become nightmare to support all Android versions and take into account
all peculiarities and bugs on Android libc (and remember, you'll need to
add run-time checks to detect real Android version on device and apply
different workarounds for different Android versions). This looks really
wrong for me as for developer, so we offer another way - just use
CrystaX NDK (which provide standard behaviour of underlying layer) and
forget about Android libc bugs/incompatibilities/etc.

CrystaX NDK is open source project, we offer it for free and we strongly
aim to continue its development and support, so practically it's better
choice than fighting with Google's NDK and fixing on your own all things
we already fixed in CrystaX NDK.

-- 
Dmitry Moskalchuk