A few functions missing from std namespace

[chaoren]

NDK version 12.0.2763256-beta1

$ cat test.cpp
#include <cmath>
#include <string>

int main() {
        (void) std::nextafter(0.0, 0.0);
        (void) std::round(0.0);
        std::log2(0.0);
        std::to_string(0);
}
$ ~/Android/toolchains/arm/bin/arm-linux-androideabi-clang++ -std=c++11 test.cpp
test.cpp:5:9: error: no member named 'nextafter' in namespace 'std'; did you mean simply 'nextafter'?
        (void) std::nextafter(0.0, 0.0);
               ^~~~~~~~~~~~~~
               nextafter
.../Android/toolchains/arm/bin/../sysroot/usr/include/math.h:245:8: note:
      'nextafter' declared here
double  nextafter(double, double) __NDK_FPABI_MATH__;
        ^
test.cpp:6:9: error: no member named 'round' in namespace 'std'; did you mean simply 'round'?
        (void) std::round(0.0);
               ^~~~~~~~~~
               round
.../Android/toolchains/arm/bin/../sysroot/usr/include/math.h:274:8: note:
      'round' declared here
double  round(double) __NDK_FPABI_MATH__;
        ^
test.cpp:7:2: error: no member named 'log2' in namespace 'std'; did you mean simply 'log2'?
        std::log2(0.0);
        ^~~~~~~~~
        log2
.../Android/toolchains/arm/bin/../sysroot/usr/include/math.h:240:8: note:
      'log2' declared here
double  log2(double) __NDK_FPABI_MATH__;
        ^
test.cpp:8:7: error: no member named 'to_string' in namespace 'std'
        std::to_string(0);
        ~~~~~^
4 errors generated.

http://en.cppreference.com/w/cpp/numeric/math/nextafter
http://en.cppreference.com/w/cpp/numeric/math/round
http://en.cppreference.com/w/cpp/numeric/math/log2
http://en.cppreference.com/w/cpp/string/basic_string/to_string

Standalone toolchain created with:

$ ./build/tools/make-standalone-toolchain.sh --platform=android-24 --arch=arm --use-llvm --install-dir=$HOME/Android/toolchains/arm

[chaoren]

There's probably a lot more. These are just the few I ran into.

[DanAlbert]

Sounds like not a regression, so actually r13 since the solution is going to take quite a bit of effort to fix thanks to autoconf being bad: https://code.google.com/p/android/issues/detail?id=82734

[technoir42]

Looks like std::to_string is still missing in r13 beta1. Will it make into the final r13?

[tzutalin]

Hope std::to_strong make into r13

[DanAlbert]

It will not be in r13. The "fix" for this is that we're working on libc++ so gnustl becomes unnecessary. r14 is probably when that will be done. It's been the entire focus of r13, but there are a lot of intermediate tasks to getting it done.

[DanAlbert]

Getting libc++ into shape depends on unified headers, which are going to take all of the r14 cycle.

[ghost]

@DanAlbert, sorry for spam, I want to know what feature of libc++_shared that is still missing to solve stack unwinding problem for either ice cream sandwich and gingerbread?

[DanAlbert]

@kangjoni76: Are you referring to the exception handling issues mentioned in the Known Issues for the last few releases? libc++ (as implemented in the NDK) has more issues than that (see the warnings in the libc++ section of our docs).

As for the exception unwinding issues, the KI list looks like it was actually more general than the problem really is. It seems to affect only armeabi (doesn't affect arm7): https://android.googlesource.com/platform/ndk/+/master/tests/device/libcxx-unwind/test_config.py. Whether or not it still affects ICS is unknown, since I don't have an ICS device handy atm.

[ghost]

yes I was referring to that case. I couldn't move on from exiting r10e release. It's still unclear to me, perhaps shouldn't official wiki to provide complete tescase exception handling progress report on ARM especially for libc++_shared part, so that we could better know edge case part about this. https://developer.android.com/ndk/guides/cpp-support.html

[DanAlbert]

Exception unwinding was broken in r10e too... In fact, it was much worse.

Actually, digging in to this to verify that it was broken in r10e, it looks like this was fixed some time during the development of r12 (the test was added early in r12). There was a misconfiguration in the test that was causing it to be skipped rather than reporting that a known failure was passing, which is why it didn't get removed from the known issues list.

I'll get the changelog updated to reflect this.

[ghost]

I'm still using gnustl_shared at r10e, well using qt5 5.6 qml is not c++ exception heavy code yet. But the Google project that is grpc in which I had filed an issue grpc/grpc#7898 still showstopper. They might use many exception code as they will to deprecate non c++11 compiler. But thank you very much anyway for considering this.

[Thooms]

Hello, I ran into the very same bug for the function snprintf (which is supposed to be part of std:: too) :) I'm on NDK version 13.1.3345770.

[sliu012]

hi all,
I resolved the issues w.r.t. "'stoi' is not a member of 'std'" ,"stddef.h: No such file or directory"
with the following steps:

1. enter the directory "android-ndk-r13b/build/tools"

2. then get the toolchain using:
   sh make-standalone-toolchain.sh --arch=arm
   --platform=android-16
   --install-dir=/somewhere/Android-16_Toolchain
   --stl=libc++

3. compile your c++11 .cpp file using the following command:
   /somewhere/Android-16_Toolchain/bin/arm-linux-androideabi-g++ -std=c++11
   -isystem /somewhere/Android-16_Toolchain/include/c++/4.9.x/
   -o test test.cpp -lc++_shared

libc++ covers the unsupported std:: functions by the default libgnustl, and "-isystem" resolves the header including problem.

[DanAlbert]

Work for O ate all of r15's time, so this is going to have to wait for r16.

[DanAlbert]

Okay, as of r16 libc++ is in good enough shape to recommend it. If you need these functions, migrate over to libc++.

Thanks for bearing with us on this one. Sorry it took so long!

[rcdailey]

@DanAlbert I get crashes in boost (something in their boost::exception code) with r15b LLVM STL that I do not get using GNU STL. I tried debugging it for a few hours but without proper backtraces in tombstones and inability to use ndk-gdb with CMake builds, I couldn't get very far. I'll try with r16 and see if it makes a difference. I'm hoping it was due to libc++ issues. Since you recommend it in r16 should be worth another try...

[scottbouma]

Sorry for the newbie request: how do I actually download the r16 beta? Thanks!

[enh]

right now, r16 is only available as a continuous build: https://android.googlesource.com/platform/ndk/+/master/docs/ContinuousBuilds.md

when there's an "official" beta, it'll be available here: https://github.com/android-ndk/ndk/wiki

[aschrijver]

With latest canary build I still have issues that seem related to this issue. See: nodejs/node#14771

[DanAlbert]

You're still using gnustl in that. See #82 (comment)

[aschrijver]

Thanks @DanAlbert !
It is not fully clear how I can configure that. I tried adding --stl=libc++ to the toolchain cmd in android-configure but that does not do it.

[aschrijver]

FYI This configuration issue is the only blocker still remaining to upgrading J2V8 to Node 8.1.2: eclipsesource/J2V8#327 (comment)

[matiwinnetou]

@aschrijver : J2V8... :)

[drywolf]

To elaborate a little bit more ... J2V8 is currently using android-gcc-toolchain to run its Android build. I had a quick look into the NDK toolchain documentation and other sources, and I think I read somewhere that the --stl=libc++ option is not supported when using GCC for the compiler. My next step now would be to try and use make_standalone_toolchain.py to get a Clang-based build running without the use of android-gcc-toolchain altogether.

However, I am unable to find a part of the documentation specifically saying that when using Clang of the Android NDK that then the libc++ problems will all go away. What I mean to say is that it is unclear to me if linking against the libc++ is fully implemented & supported for the Android NDK at this point.

I will post my results here once I'm further down this road.

[rcdailey]

According to other posts I've read, r16 will be when libc++ is "ready"

…

On Thu, Aug 17, 2017, 7:28 AM Wolfgang Steiner ***@***.***> wrote: To elaborate a little bit more ... J2V8 is currently using android-gcc-toolchain <https://github.com/sjitech/android-gcc-toolchain> to run its Android build. I had a quick look into the NDK toolchain documentation <https://developer.android.com/ndk/guides/standalone_toolchain.html> and other sources, and I think I read somewhere that the --stl=libc++ option is not supported when using GCC for the compiler. My next step now would be to try and use make_standalone_toolchain.py to get a Clang-based build running without the use of android-gcc-toolchain altogether. However, I am unable to find a part of the documentation specifically saying that when using Clang of the Android NDK that then the libc++ problems will all go away. What I mean to say is that it is unclear to me if linking against the libc++ is fully implemented & supported for the Android NDK at this point. I will post my results here once I'm further down this road. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#82 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABr6dlk0jKP1v0GC2ICzx7BjLx1dGT2Bks5sZDHsgaJpZM4ILFSd> .

[aschrijver]

I think you will have to try with the canary build, like I did for 8.3.0: nodejs/node#14783 (comment)

[drywolf]

Thanks for the hints

[DanAlbert]

Can we move this discussion to a nodejs bug please? This bug is fixed. Any issues nodejs is having are not related to this bug.

Feel free to CC me on the bugs. I'm happy to help, just don't want to bog down this thread with unrelated conversation :)

[ec1oud]

What about log2, is it included yet?

[enh]

the test.cpp in the original example builds fine with NDK r17.