make stand alone toolchain on linux gets the headers wrong

[AppCoder]


I'm doing:

$ANDROID_NDK/build/tools/make-standalone-toolchain.sh --verbose --arch=arm --platform=android-21 --stl=libc++ --install-dir=$NDK_STANDALONE

on OSX Sierra and Ubuntu 16.04

On OSX boost http://www.boost.org/ and avro https://avro.apache.org/ build fine.

On Ubuntu, boost builds it's own libatomic (likely not finding the NDK versions) and avro fails with

In file included from /opt/workspace/avro/impl/ResolverSchema.cc:20:
In file included from /opt/workspace/avro/api/ResolverSchema.hh:27:
In file included from /opt/workspace/avro/api/Boost.hh:60:
In file included from /opt/workspace/install/armeabi/boost/include/boost/type_traits.hpp:93:
In file included from /opt/workspace/install/armeabi/boost/include/boost/type_traits/is_complex.hpp:11:
In file included from /opt/workspace/aws-sdk-cpp/toolchains/android/armeabi-standalone-clang-android-21-libc++_shared-13002/lib/gcc/arm-linux-androideabi/4.9.x/../../../../include/c++/4.9.x/complex:246:
/opt/workspace/aws-sdk-cpp/toolchains/android/armeabi-standalone-clang-android-21-libc++_shared-13002/lib/gcc/arm-linux-androideabi/4.9.x/../../../../include/c++/4.9.x/cmath:313:9: error: no member named 'signbit' in the global namespace
using ::signbit;
      ~~^
/opt/workspace/aws-sdk-cpp/toolchains/android/armeabi-standalone-clang-android-21-libc++_shared-13002/lib/gcc/arm-linux-androideabi/4.9.x/../../../../include/c++/4.9.x/cmath:314:9: error: no member named 'fpclassify' in the global namespace
using ::fpclassify;
(and some more)

Digging deeper I find that the Ubuntu standalone tool chain has added

 -isystem /opt/workspace/build/Linux/armeabi/toolchain/sysroot/usr/include

in addition to the -sysroot option.   This appears to be wrong (masking some part of the libc++ headers) because when I run the compile by hand without the -isystem option, it works.

Any hints on where I'd fix that?

          Dan S.


[AppCoder]

And the answer is, CMake v 3.8.1 (which I had on the Ubuntu image) tries to do you favors you do not want, vs. 3.7.2 (which you get with mac ports.)
Sorry for the wrong list topic; born from the frustration of "just make a docker image so we can put it on the CI server" taking more than an hour.

[Dan Albert]

If your project is CMake you're probably better off not using the standalone toolchains. We ship CMake support in the NDK now ($NDK/build/cmake/android.toolchain.cmake). If you're using 3.7, CMake also added their own NDK support, but we don't maintain that so I can't guarantee anything :) With CMake 3.7+ you'll actually need NDK r15 (which is due to release in a week or so) if you want to use ours, since 3.7's support actually broke our toolchain file :(

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/415893a1-a385-455e-a12e-2971dac0c190%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[AppCoder]

On Tuesday, May 30, 2017 at 5:58:26 PM UTC-4, Dan Albert wrote:

If your project is CMake you're probably better off not using the standalone toolchains. We ship CMake support in the NDK now ($NDK/build/cmake/android.toolchain.cmake). If you're using 3.7, CMake also added their own NDK support, but we don't maintain that so I can't guarantee anything :) With CMake 3.7+ you'll actually need NDK r15 (which is due to release in a week or so) if you want to use ours, since 3.7's support actually broke our toolchain file :(

My goals are to write cross platform C++ code and utilize bunches of FOSS stuff to stand on the shoulders of giants/not reinvent the wheel.
I want to be able to run my native code on my host platform for unit tests etc.  I'm living with r13b and clang/stdc++ shared/c++11.

Stuff I want to use for C++ development, and how they relate to CMake/standalone toolchains etc.

Boost: supported bjam works with standalone tool chain, dead cmake project (last commit 2+ years old), I think the experimental cdep supports it
     http://www.boost.org/

aws-sdk-cpp: uses cmake 3.7 to build a standalone tool chain.   Not very good about taking externally provided tool chain, can't find it in the cdep support list
      Note this magically gets me curl/openssl and zlib (not required for android, but nice for host builds) built as well....
     https://github.com/aws/aws-sdk-cpp
     https://www.openssl.org/
     https://curl.haxx.se/libcurl/
     https://www.zlib.net/
 
avro c++: cmake 3.7 auto detect and standalone tool chain work (host based test suite needs conditionals to skip on cross compile), no mention of cdep support
     https://avro.apache.org/

http://luajit.org/: cmake 3.7 auto detect and standalone tool chain work, no mention of cdep support

botan: has it's own python configure set, standalone tool chain seems to be the way to go
     https://github.com/randombit/botan

My concerns are that I'm on a schedule, and will be, so things that involve re-writing working build systems, and updating them to track updated releases, have lots of strong marks against.   If it were all my code, and there were some reasonable promise that it would continue to work for 12+ months, I'd gladly use the supported built-in options.   Right now the standalone tool chains give me some level of confidence that the same level of C++ support, API level, and stdc++ library get used for everything I'm pulling together (my current hack is a shell script to do aws-sdk-cpp first, and pass the tool chain to cmake for avro & lucjit, and play with boost/bjam and botan's choice of build systems; this gives me libraries, and standalone test programs that build on OSX/ubuntu in a docker image for the host and armeabi).

When I see "use ours, since 3.7's support actually broke our toolchain file" I have the similar frowny emoticon.   Why is there a "theirs and ours"?   Is there some split between or policy restriction between the cmake development team and Google NDK support that forces the replication of effort (and could it go away)?

Any elaboration on insights or warnings into what to do next if I want to do C++ development for android going forward with a bunch of external project dependencies?

[Felix Homann]

Am Dienstag, 30. Mai 2017 23:58:26 UTC+2 schrieb Dan Albert:

If your project is CMake you're probably better off not using the standalone toolchains. We ship CMake support in the NDK now ($NDK/build/cmake/android.toolchain.cmake). 

Could you please give an example on how to use it (which options, toolchain file etc.?) from the command line to build for Android?

Thanks in advance,

Felix

[Felix Homann]

One more note: The shipped CMake is still broken! See https://issuetracker.google.com/issues/37102629

[Dan Albert]

My goals are to write cross platform C++ code and utilize bunches of FOSS stuff to stand on the shoulders of giants/not reinvent the wheel.

Hard to see how using CMake counts as reinventing the wheel. Understood that migration takes time though. If what you have is working for you, stick with it :) It may be worth looking at though to see if it would save you time in the long term (given the large list of third-party projects you depend on though, it may not).

When I see "use ours, since 3.7's support actually broke our toolchain file" I have the similar frowny emoticon.   Why is there a "theirs and ours"?   Is there some split between or policy restriction between the cmake development team and Google NDK support that forces the replication of effort (and could it go away)?

Both us and CMake were both working on this at about the same time, and neither of us was aware of the other. We're working on combining the two in a backward compatible manner. 

Could you please give an example on how to use it (which options, toolchain file etc.?) from the command line to build for Android?

It's just a toolchain file. You mostly use it like you would any other cmake toolchain file:

    $ cmake -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake $OTHER_OPTIONS

The options it accepts (STL, ABI, API, etc) are listed in the toolchain file: https://android.googlesource.com/platform/ndk/+/master/build/cmake/android.toolchain.cmake

One more note: The shipped CMake is still broken! See https://issuetracker.google.com/issues/37102629

Fixes for this got submitted recently, they just need to be released. 

On Thu, Jun 1, 2017 at 3:24 AM, Felix Homann <showlabor....@gmail.com> wrote:

One more note: The shipped CMake is still broken! See https://issuetracker.google.com/issues/37102629

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/93d6e1fd-f6b8-43fb-b740-b92758c19fad%40googlegroups.com.