Skip to content
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

Multiple static runtimes in Android NDK #813

Open
afjoseph opened this issue Sep 18, 2018 · 0 comments

Comments

Projects
None yet
1 participant
@afjoseph
Copy link

commented Sep 18, 2018

This is more of a question rather than an issue: C++ Library Support guide in developer.android mentions that only multiple STLs defined in a single app can cause numerous unknown issues.

Here's the relevant excerpt from the document:

In this situation, the STL, including and global data and static constructors,
will be present in both libraries. The runtime behavior of this application is
undefined, and in practice crashes are very common. Other possible issues
include:

 * Memory allocated in one library, and freed in the other, causing memory
   leakage or heap corruption.
 * Exceptions raised in `libfoo.so` going uncaught in `libbar.so`, causing your
   app to crash.
 * Buffering of `std::cout` not working properly.

There's also another older document in the NDK repo that mentions the same


On the other hand, if you have two shared libraries in your project
--
  | (e.g. libfoo.so and libbar.so) 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.

I see that both libyoga.so and libfb.so use c++_static runtime, which means that any other 3rd-party library existing in the app must use c++_shared or they might cause and incompatibility issue since using something like gnustl_static will cause multiple versions of the STL to exist in the same app multiple times.

I think the default for r18 will be c++_shared according to one of the main maintainers of the NDK project.

Can you please advise if the scenario above is possible? Also, do you think it would be wise to simply make both with a c++_shared STL.

Thanks again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.