I think anyone who has compiled for android has come across the ‘std::to_string is not a member of std’ error. There appears to be 2 common solutions on the forum
reimplement std::to_string yourself and include it in all necessary files
use c++_static instead of gnustl_static
A long time ago I tried reimplemented std::to_string myself, only to find gnustl_static is missing all sorts of other basic functions like std::round and c++11 string converters like std::stoi, std::stod, etc. As I recall gnustl_static had no support for std::future.
Using c++_static fixed all these problems and I was happy.
Now I would like to change my workflow from using cocos2d-x and its source code, to using the Cocos App with Framework and prebuilt libs. Using c++_static with the prebuilt framework does not work. I created a github issue for this and the response was ‘currently c++_static is not supported’.
So my question is, why are we supporting gnustl_static and not c++_static? Is there is a reason we can’t switch to c++_static?
Requiring cocos2dx users to reimplement std functions is obviously a bad solution. As @ricardo says “Game Designer/Developers should be in charge of designing the game, and coding the game, but things outside the game should be provided by cocos2d”
any idea why? we are using libc++ on Xcode and as far as I know the clang/llvm lib is more complete than the gcc one…
My guess is that it should be possible to use gcc with libc++ on Android.
I guess gcc is the default one, although some users are using clang instead.
But my point is that users can mix the gcc compiler with the clang STL lib.
The inverse works for use: use clang compiler with gcc STL lib.
yes… that bug is about stlport… stlport was being used in Android NDK because the default one was broken, but today nobody uses stlport anymore, specially since clang is part of the NDK.
probably you are right. Not sure if changing the std lib will break ABI.
but using just one lib (clang stdlib) as the default std lib, is a good thing for us since we will deal with less bugs and maintenance issues. Just one lib for ios and android.
I never made it to work with gnustl_static and gcc with all the c++11 features. I was getting crashes in simple lambdas, as mentioned std::to_string was missing and much more, so i’ve switched to c++_static and clang long time ago.
Using C++_static is okay for the main body of cocos2dx.
But SDKBOX requires gnustl, which is outright stupid. This is causing severe problems. We spent time integrate sdkbox only to find out that it forces gnustl, which cocos2dx itself doesn’t even do in 3.7, and it’s totally an unnecessary requirement.
Basic consistency seems just thrown out of the window. Higher level coordination is a MUCH NEEDED FEATURE in the cocos eco development team I guess. Make cocostudio 2 support image formats that cocos supports, make sdkbox compile env consistent with cocos2dx.
If cocos is going to push any paid service, with this level of professionalism I sure am not gonna jump the wagon.
I’m using SDKBOX FlurryAnalytics plugin and I have
NDK_TOOLCHAIN_VERSION := clang
APP_STL := c++_static
in my Application.mk, I compile for armv7, armv7a and x86 and everything works perfectly fine
Not sure if I correctly understand you about genlibs, but that’s what I have in Android.mk
LOCAL_STATIC_LIBRARIES := cocos2dx_static
LOCAL_WHOLE_STATIC_LIBRARIES += PluginFlurryAnalytics sdkbox