Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Static or shared C++ runtime for 3rd-party Java library #796
I'm compiling a 3rd-party Java library for Android that uses JNI. I read the relevant pages on adding C++ support on developer.android but I'm still confused about a couple of issues regarding C++ STL runtime that I was hoping I could clear up here:
1- My library has no control over the app it will be embedded in, so I don't know if there will be other libraries that might use a static/shared STLs. If I use a static C++ runtime with
2- If I use a shared C++ runtime with
Ideally, I'd like to have a very stripped down version of a static c++ runtime with (
Please advise and thank you.
As you've discovered, there's some nuance here and I'm having some trouble forming a simple answer. Bear with me :)
The first thing to note is that there's no difference between the static and shared variant of the STL when building a static library. Static libraries are not linked, and static vs shared STL is a link-time decision. You do have to name one of them for the build system, but it's not a real decision for a static library; the actual choice is deferred to the user of the static library.
Second: yes, if you use libc++ your users must use libc++. If you use gnustl, your users must use gnustl. If you want your users to have both options you need to provide two libraries.
The answer is pretty straightforward if you and your users are both using at least NDK r16: use libc++ shared. gnustl is no longer relevant at this point. If you ship a shared library you should use the shared STL because to do otherwise gets into the multiple STL issues you read about.
To answer your specific questions in case the above doesn't clear things up:
As above, you must distribute both a libc++ and gnustl version of your library if you want your users to have that choice.
There's technically a loophole here if you're distributing a shared library and do not use the STL anywhere in your library's interface. This loophole violates ODR so is technically undefined behavior, but it's something people have been doing that mostly works. Link the static version of an STL and use a version script to ensure that they are linked with hidden visibility. i.e.
Not everything works if you do this. Standard exceptions thrown from your library can not be caught by your users.
It's... tricky. libc++ and gnustl mangle their names differently so they are actually distinct types... but there are a few types within each of them that do mangle the same way (
Thanks @DanAlbert. That cleared up everything.
This could just be me since I was misinformed about the situation, so please take my criticism with a heavy grain of salt and thanks again.
@Obaied, you cite the old document that says,
This is not exactly true. Let me explain.
I'm always split between trying to give the simple answer and trying to give all the (probably confusing for people that haven't already been down this road) detail necessary to give the most correct answer like @alexcohn has. Like I said, there's a bunch of nuance, and I'm not sure what the right thing to put in our docs is that doesn't have newcomers running away screaming.
Maybe it'd be best for me to keep the straightforward but incomplete answer in the docs but upload a sample that shows all the gross tricks?
@DanAlbert, If I can make a humble suggestion, I think this post was much more illuminating that the current docs, so I highly encourage you guys cherrypick some of the answers provided by you and Mr. Cohn.
Thanks again to both of you. This was very helpful.