Inconsistency in cmath between arm64-v8a and armeabi-v7a

[DoDoENT]

When I compile my program which uses Eigen library for arm64-v8a ABI, everything compiles without any problem (GCC + libstdc++), however when ABI is set to armeabi-v7a, I get following errors:

error: 'std::log1p' has not been declared
error: 'lrint' is not a member of 'std'
error: 'std::round' has not been declared

Same happens if I use Clang (obviously a STL issue).

If I try using GCC + libc++, then in both arm64-v8a and armeabi-v7a I get this error:

/Users/dodo/android-sdks/android-ndk-r12b/sources/cxx-stl/llvm-libc++/libcxx/include/tuple:291:72: error: 'constexpr const _Hp& std::__ndk1::__tuple_leaf<_Ip, _Hp, <anonymous> >::get() const' cannot be overloaded
 _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11 const _Hp& get() const _NOEXCEPT {return value;}

The only combination which does compile for both armv7 and armv8 is clang+libc++, but we currently cannot use that due to issues #108, #137, #21, #9 and #156.

Any advices?

[DanAlbert]

What's you APP_PLATFORM set to for armeabi-v7a in the first example? The first thing that comes to mind is that older platform levels actually were missing a ton of things that should have been there, and targeting any 64-bit ABI means you're targeting at least android-21.

The second issue (GCC + libc++) is probably just an old incompatibility that should clear up with r13 since we've updated libc++ and removed all the local hacks (I haven't tested that theory, but it certainly looks like that kind of error). By the look of things, I should be able to repro it with just #include <tuple>, correct?

Eigen is probably something that we should add to our pre-release validation. I've made a note of it in our docs.

[DoDoENT]

APP_PLATFORM is android-23. It happens also with android-24. We use android-23 for our production builds.

The second issue can be reproduced just by including <tuple>.

[DanAlbert]

The first issue is roughly the same as http://b.android.com/82734. tl;dr autoconf is awful so you either get all of c99 math or none of it. Since gingerbread (which we build libstdc++ against) didn't have support for all of it, it gets none of it.

Looks like another argument for our plan of making it easy to statically link the latest libm (possibly doing so by default). I think unified headers might actually get configure to shut up, but it's possible that will cause other problems since those symbols won't actually be available on Gingerbread...

The above all does hang on the assumption that this is not a regression. If this worked in r10 or r11 then there might be something else going on (though it could just be something that came up with our updated gcc).

Haven't checked the second issue yet (I'll do that now).

[DanAlbert]

Since gingerbread (which we build libstdc++ against) didn't have support for all of it, it gets none of it.

To clarify, since we build libstdc++ against android-9, the header that defines all the configuration constants will report not having C99 math even if you're targeting a newer API level :\

[DanAlbert]

As for the second issue here (GCC + libstdc++), I couldn't repro with r12b. Source file is just #include <tuple>, using APP_STL := c++_static, NDK_TOOLCHAIN_VERSION := 4.9, targeting armeabi-v7a android-23 (tried 9 as well).

[DoDoENT]

Try with this example.

It was built to show some different GCC + libsdc++ issue, but it can be also used to demonstrate tuple problem on GCC + c++_static configuration.

[DanAlbert]

Yep, that repros, thanks. Checked against my r13-beta1 build as well, and it looks like the libc++ update does fix the GCC incompatibility.

[DanAlbert]

Looks like each combination of libc++/gnustl clang/gcc works for this example now (going back to at least r14).