Here is a link to the github issue I opened.
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.
So that’s what is being done currently with gnustl.
Although I am skeptical that this is guaranteed to work. AFAIK linking libs from different compilers is not guaranteed to be ABI compatible.
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.
2 Likes
So everyone agrees switching to clang / c++_static is the way forward?
What is the next step?
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 would also like to start using SDXBOX.
Any progress being made towards this problem?
I hear you, We’re working on providing c++ static build for SDKBOX, I think we’ll release it for the next release in 3 weeks.
4 Likes
Is there any update on this?
I’m currently wondering whether I should use gnustl_static or c++_static.
I’m facing all these missing function errors from std and trying to use different ones but it gets really difficult.
Is there still a problem using c++_static?
Is it possible to use cocos2d-x static lib and SDKBOX with c++_static?
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
2 Likes
Thanks for the insight.
Do you also know if this works when using cocos2d-x as a static-lib, using the new genlibs command?
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
Cocos2d-x recently added the feature of creating a prebuilt static library out of the cocos2d-x code.
This way you never have to rebuild cocos2d-x.
In some thread (unfortunately I forgot which one), I read that changing APP_STL or NDK_TOOLCHAIN_VERSION might break this from working.
Did you do something, so that you don’t have to recompile cocos2d-x?
Yes, SDKBOX now also provides c++static support
I also wrote a tutorial about how to generate a prebuilt version of cocos2d-x yourself here. it’s a bit out dated, only tested with 3.8 version
1 Like
Well, there are two makefiles that affect Android native code compilation: Android.mk and Appliation.mk
Android.mk contains list of source files and other stuff for you game. Different parts of cocos engine are linked to your app as static libraries and each one of them has it’s own Android.mk. You can see all the libs in obj/local folder of your android project. If you change something in your Android.mk, all you source files will be recompiled, but cocos source files won’t.
Application.mk contains global settings for the whole app - target architecture, standard library, optimisation level etc. Changing something in Application.mk will cause all your sources and cocos sources to be recompiled.
You can set parameters in Application.mk once and for all, and engine sources will never be recompiled unless their makefiles change.
3 Likes
Thanks a lot, I think I finally understood it now.
I’ve been using c++_static when I compile the static library from source directly in the project with success with the core modules since cocos 3.3 and tested with cocos 3.13.1. I even use c++14 as I always like using the latest and greatest language features. In a new project I tried doing the static build using gen-libs and it was a pain to get it to work but was able to utilize c++_static by first doing global search and replace in cocos build directory Application.mk of APP_STL :=gnustl_static with APP_STL := c++_static. I also set an environment variable export ANDROID_STL=c++_static as one of the cmake files showed up using that as a default if no APP_STL was defined. I then ran
cocos gen-libs -c -p ios -p android --app-abi armeabi:x86 -m debug -m release
The build “failed” but it still generated the static libraries in
tools/simulator/frameworks/runtime-src/proj.android which I then copied over to
prebuilt/android
I was then able to link, build, and run my android project successfully with APP_STL := c++_static in my Application.mk in my Android project!
The reason why the “build” failed is some of the cocos third party libraries, spidermonkey in this case and also those mentioned in this thread, are specifically linking to the gnustl_static even though it is older and not C++11 compliant. Since I don’t use those libraries I don’t care but others that do will be unable to use c++_static until they switch over.
It also seems that you cannot easily just compile a static library project with NDK without it being part of another executable which is how the gen-libs works by building it with the “test” projects and then copying the intermediate libraries over when its done building.
1 Like