Skip to content

Eliminate libc++_shared.so dependency on Android? #17

@gavv

Description

@gavv

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:

$ aarch64-linux-android-readelf -d ./libroc.so | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libc++_shared.so]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.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?

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions