0

I am building an application on Android using NDK and V8. I would prefer to use C++11 and GNU STL for features such as shared_ptr; however, the V8 build system seems to be hardcoded to use stlport_static as its STL variant.

Even when patching the build system to generate a fully self-contained library, V8's build does not statically link STLport into its .a files (which is to be expected), and thus I get hundreds of linker errors from unresolved symbols in libv8_base.a et al. I also do not see any way to indicate to ndk-build that it should link in stlport_static when I am using a different STL variant.

Is there a reasonable pattern to linking in stlport_static while using gnustl_static, or, better yet, is there a way of building Android V8 against gnustl_static instead?

Community
  • 1
  • 1
fluffy
  • 5,212
  • 2
  • 37
  • 67
  • Does your native code talk to `libjv8.so` directly, or to its static libs? Or your Java loads the two independent shared libs? – Alex Cohn Nov 26 '14 at 05:34
  • My native code talks to `libv8_base.a`, and `libv8_base.a` depends on the `stlport_static` libraries. I could just use `stlport_static` myself but I *really* want `shared_ptr` and proper move semantics in my containers... In any case I am not building a `.so` of v8, as that doesn't seem to even be an option. – fluffy Nov 26 '14 at 08:15
  • 1
    Now open in the AOSP bug tracker: [Issue 216331: STLport does not support C++11](http://code.google.com/p/android/issues/detail?id=216331). – jww Jul 17 '16 at 22:52

1 Answers1

1

You have a problem. Well, mixing different STLs in separate .so's is possible, with extra care; but using two STLs inside one .so is simply impossible.

You either need to implement your own shared_ptr (no big deal), but then you will face the same issue for every other feature that exists in gnustl and not in stlport.

Or you need to port V8 to gnustl (and I am afraid that the MIT license does not allow this).

Alex Cohn
  • 56,089
  • 9
  • 113
  • 307
  • It looks like gnustl and stlport both use different internal symbols for all of their implementation classes, though, so I don't see what makes mixing them within a .so impossible. But what in the MIT license and/or modified GPL prohibits V8 from linking in gnustl? Is this why V8 only supports stlport? Anyway, it's looking like it'll be easier to just pull in `boost::shared_ptr` instead, which I was hoping to avoid but oh well. – fluffy Nov 26 '14 at 19:11