-
-
Notifications
You must be signed in to change notification settings - Fork 14
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
Eliminate libc++_shared.so dependency on Android? #17
Comments
Yes I agree with that problem on |
For android library we can remove STL dependency with |
I didn't try it yet. If LDFLAGS will work well, let's start with it. Later we can add a scons option to enable static-libstdc++ or disable libstdc++ at all. IIRC Android docs claim that static-libstdc++ is dangerous (i.e. is not guaranteed to work in all cases), so we should carefully test it. |
The quoted part part is done in #55. The remaining part for this issue is to adjust build script for Android to build libroc with static libc++, as suggested in #17 (comment) The build script to be modified is here: https://github.com/roc-streaming/roc-java/blob/main/scripts/android/build_roc.sh |
On Android, if AAR or APK has native libraries depending on libc++_shared.so (C++ STL from Clang), they should ship a copy of the library.
This, theoretically, may lead to problems if the user wants to use more than one native library and they depend on different versions of libc++_shared.so. It seems that the official recommendation is not use more than one native library.
In our case, both libroc.so and libroc_jni.so depend on libc++_shared.so. Here are the dependencies of libroc.so:
Here, libc++_shared.so is the only library needed to be shipped. Other libraries, AFAIK, are guaranteed to be available on every Android system.
But actually, I think we could get rid of the dependency on libc++_shared.so:
For libroc.so, we can link it statically into libroc.so or maybe even don't use it on Android at all (Roc does not use much of STL).
For libroc_jni.so, we can actually don't use C++. It seems that most files can be just renamed from .cpp to .c. It seems that the only C++ feature we're using is std::mutex. We can replace it with pthread_mutex for now (and add non-unix implementation later when needed), or maybe we can somehow move synchronization from C++ side to Java side.
Port JNI bindings from C++ to C #55
@MatteoArella Thoughts?
The text was updated successfully, but these errors were encountered: