New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add cocos2dx_static #715
Add cocos2dx_static #715
Conversation
As mentioned in NDK_ROOT/documentation.html. LOCAL_STATIC_LIBRARIES So we can not use LOCAL_STATIC_LIBRARIES when building a static library. |
Thanks for reviewing. Could you send me the command you use to build? I am trying to build with either gnustl_static or stlport_static. My build is successful but I am seeing an error at runtime in libc. |
I use tests/test.android/build_native.sh to build tests. E:/cocos2d-x/tests/test.android/obj/local/armeabi/libcocos2d.a(CCImage.o): In fu There are many other errors. LOCAL_STATIC_LIBRARIES := curl_static_prebuilt in tests/Android.mk, but can not resolve the problem. |
I'll check this when I get back - you can dump the symbols from the On Feb 8, 2012, at 6:25 PM, minggo
|
May be my question is: |
I think I find the method. LOCAL_STATIC_LIBRARIES := cocos2dx_static in every module that depends cocos2dx. |
There is a WHOLE_STATIC_LIBRARY option somewhere... On Feb 8, 2012, at 7:09 PM, minggo
|
I see that next cocos2d-x update will be pain in the ass for android-platform as previous :\ To many changes that do nothing usefull... |
I think it is useful, because many developers meet error when building with NDK. |
I mean this romp with submodules and dynamic_cast. Static linking now strictly necessarily, confirm this. I've spended some time to find reason of app crashing after last update and damned author of "change to dynamic_cast" after found it :) In my case, application must use LOCAL_WHOLE_STATIC_LIBRARIES to cocos2d-x to prevent jni-functions stripping. You're must be very careful with such changes. This is reasons for some developers thinking that cocos2d-x not ready yet. Then we all know that it is very good library and ready for production :) |
Thank you moadib. |
I use LOCAL_WHOLE_STATIC_LIBRARIES in cocos2dx/Android.mk. |
I didn't examine module system yet. But for 0.11.0 it is nessesary to move all dependencies from cocos2d-x .mk to application .mk for static linking. |
Please see my recent updates to the pull request. I've added LOCAL_WHOLE_STATIC_LIBRARIES to the cocos2d-x makefiles. Here is the NDK only project I am using (no Java files) Makefile used to integrate cocos2d-x is here: Note that I am trying to move away from crystax C++ libs and to gnustl from the Android NDK. I am getting errors from spurious symbols defined in libjpeg : |
My next steps will probaly be to build libjpeg, libpng, libxml2 from source... |
Please discuss if this is the right direction for the project. Here are my goals :
Thanks! |
We only provide source for developers. Could you please modify the codes from cocos2d-x(including HelloWorld, tests and cocos2dx), not only for cocos2d-x/cocos2dx. Then our environment will be the same. We divides game logic into two parts: such as HelloWorld/Classes and HelloWorld/android. All the .cpp files under HelloWorld/Classes are platform-independent. So there are two Android.mk(HelloWorld/Classes/Andorid.mk and HelloWorld/android/jni/helloworld/Android.mk). Of course we can only have one Android.mk just as previous version: including all HelloWorld/Classes/*.cpp files in HelloWorld/android/jni/helloworld/Android.mk. Then obj files will be put in HelloWorld/android/obj/local, not in HelloWorld/android/obj/local/TARGET_ARCH_ABI. This can cause error when building multiple targets(armeabi and x86) at the same time. Suppose building armeabi first, x86 second. When building x86, the objs are exist in HelloWorld/android/obj/local, then it will not rebuild files under HelloWorld/Classes. This cause link error, because the objs are arm format. |
Our goals are not in conflict :)
We both agree? ie, move away from using Crystax C++ libs. Is there any dependency on external libs other than Crystax?
We both agree.
We both agree. Further, I think we should build libjpeg, libpng and libxml2 from source also.
OK. Agreed. Primary deliverable must be source code.
I think both are possible. ie,
|
I use LOCAL_WHOLE_STATIC_LIBRARIES in other module that dependent cococos2dx and add There is not error, and prevent jni-functions stripping. |
I will take a look at HelloWorld, classes and the x86 Android build tomorrow. |
But it will add compile time. I think we can offer source code, but use prebuilt lib as default. Developers can use source code if they want to.
Because at first, stl is not supported by NDK, so we use Crystax version to build libpng, libjpeg. We should rebuild them. You are appreciated if you can do it for the community. As far as I know, C++ now can not receive input message. |
folecr, moadib I have pulled a request in #716. Now I have to include libpng, libjpeg and so on in every module that dependents cocos2dx. And I think this pull request should be closed. |
Hi moadib, I think using RTTI is required, otherwise the code would be too fat. |
OK.
Yes. Thanks. |
fixed cocos2d#715: make sure selected image is valid
fixed cocos2d#715: make sure selected image is valid
fixed #715: make sure selected image is valid
Add a cocos2dx_static library.