Ok, i dont think i fix it, most like iāve changed some things back.
The call from touchesJNI in the end goes to the CCMenu class in the ccTouchBegan() method and,
after that in the itemForTouch method. In the last it use dinamic cast for casting CCObject object in to CCNode one:
@ CCNode* pChild = dynamic_cast<CCNode*>(pObject);@
and it looks like it succeded, but after it try to acces any member of casted instance it just goes downā¦ probably execfault.
So it seems that Android got some issues with using RTTI in native code. So i just changed dynamic cast on to regular one:
@ CCNode* pChild = (CCNode*)pObject;@
Like it was in the previus version of that class(0.10.0).And its all work fine now.
And here is my question - Does dinamic cast gives some real performance benefits instead of regular object type casting?
In that case, it is realy some kind of NDK issue, becouse iāve checked that and in this case: CCNode* pChild = dynamic_cast<CCNode*>(pObject);
pObject is not null, it does contain pointer. But i think that danvik does not allowed access to , such way, dinamically memory allocated object. And thats why when we try to acces this object we got whis āsilentā crash. I may be wrong offcource.
And what will be the final solution? will it be changed back w/o dynamic_cast, or may be there is some way to make it work with it?
P.S. Just now iāve read intresting thing in cplusplus documentation of NDK:
II.3. Static runtimes:
>
Please keep in mind that the static library variant of a given C*+ runtime
SHALL ONLY BE LINKED INTO A SINGLE BINARY for optimal conditions.
>
What this means is that if your project consists of a single shared
library, you can link against, e.g., stlport_static, and everything will
work correctly.
>
On the other hand, if you have two shared libraries in your project
which both link against the same static
runtime, each one of them will include a copy of the runtimeās code in
its final binary image. This is problematic because certain global
variables used/provided internally by the runtime are duplicated.
>
This is likely to result in code that doesnāt work correctly, for example:
>
memory allocated in one library, and freed in the other would leak
or even corrupt the heap.
>
exceptions raised in libfoo.so cannot be caught in libbar.so .
>
the buffering of cout not working properly
>
This problem also happens if you want to link an executable and a shared
library to the same static library.
>
In other words, if your project requires several shared library modules,
then use the shared library variant of your C*+ runtime.
It looks like we have a secont type of error when exceptions raised in libgame.so cannot be caught in libcocos2d.so.
but after iāve tryed to change APP_STL := stlport_static to APP_STL := stlport_shared in application.mk and recompile it iāve got crash on application startup. My skills are not enouth to understand it , so any help will appreciate
Thank you Serg, its working that way!)
But, as matched in your topic it is have some licence differens. Itās doesnt metter realy for me now, but itāll be nice to know the difference.
Most companies avoid GPL licensed products for a host of reasons. Those reasons include 1) Itās not clear if the runtime library exception applies to static linking and 2) itās not clear if the license requires your game code to be open source if it is statically linked.
So using gnustl_static is not an option for companies wishing to avoid legal problems.
I also have the crahs in itemForTouch (NDK r7). I had other problems when using gnustl, such as crash with std::string. I tried to group everything in one library (one single .so) and itās not better. I will probably revert the RTTI locally. I donāt see any advantage to using it.
