v8 cannot be statically linked with libadblockplus for android

[sergz]

v8 configuration for android is using stlport but in libadblockplus (+tests) we are not using stlport and we are using C++11 (I'm not talking about syntax, it's about std library, e.g. <thread>, <memory>).

The issue is that after updating of v8 (see #1197) we cannot link a binary because there are no such symbols in c++_static. We are linking our code with c++_static but v8 was compiled to be linked with libstlport and there are no functions required by stlport in c++_static. Actually we even should not link anything compiled with stlport with c++_static instead of libstlport as it is happening now.

I see only a couple of ways to solve it:

• make changes in v8 (at least build/android.gypi or build/standalone.gypi in later versions) to use normal std lib instead of stlport.

I would not go with that option because it looks unreliable and too difficult to support. In particular we don't know whether there are some "optimizations" based on the fact that stlport is used. As well as it can be tricky to track all changes in v8 and re-apply our build patches or even properly patch the everything.

• switch to stlport in libadblockplus and all derivatives and use e.g. boost as far as normal std library is not available.

I'm not sure that it actually worth the efforts, so far it's not a bottleneck in the performance but it requires a lot of work because all derivatives will have to use stlport or link libadblockplus dynamically. In addition it requires to pull boost which looks like an overhead here. I would go with that option if we cannot use the following one:

• build v8 as a shared object (.so). (however v8 is still statically linked with libstlport_static.a).

That looks the best option because we can still use whatever we want in our codebase and we don't have to plunge into the details of v8 and bother our self by having our patches for v8.
(I have quickly googled some potential troubles here, the only one thing I have found is ​https://code.google.com/p/android/issues/detail?id=28329 which is likely not an issue in a recent Android NDK).

Additional note for further tickets after making the decision

We cannot fetch only v8 repository anymore, we have to use gclient because v8 team is not going to support it (​https://codereview.chromium.org/876323002/ that change is actually already required to compile v8 for android because we don't use icu). We also cannot switch to gclient with our current version because it references some repositories which are not available anymore. And of course with gclient we need to solve the question about availability of repositories and repeatability of builds.

Because of the above points and the fact that we are not contributing to v8 I would propose to create two repositories:

• v8-project. It should contain all scripts to fetch and compile v8 for used platforms (MS Windows, Android, Linux, OSX). May be we could even run v8 tests here.
• v8-binaries. It should contain compiled binaries and v8 headers. It should simplify the usage of v8 binaries as well as save a lot of time because we are not developing v8 but it takes very long to rebuild it each time we rebuild libadblockplus.

[sergz]

I have built libv8.so for linux and android and managed to run our tests (from libadblockplus) dynamically linked with libv8.so on Android 4.1.2 (and of course on linux).

In addition:

• before

  #ndk-depends ../libadblockplus-master/build/android_arm.release/tests 
  tests
  libstdc++.so
  libm.so
  libdl.so
  libc.so
  

• after (v8 is also updated here to 4.3.15)

  #ndk-depends build/android_arm.release/lib.target/libv8.so 
  libv8.so
  libstdc++.so
  libm.so
  liblog.so
  libdl.so
  libc.so
  #ndk-depends -L build/android_arm.release/lib.target/ ../libadblockplus/build/android_arm.release/tests 
  tests
  libv8.so
  libstdc++.so
  libm.so
  liblog.so
  libdl.so
  libc.so
  

liblog.so seems optional, I will try to get rid of it.

The following part is some kind of documentation of important steps and moments for non-android folk how to reproduce it.

Since it's a native application to run it I did the following steps

#adb push path-to-libv8.so /data/local/tmp
#adb push path-to-tests /data/local/tmp
#adb shell
#cd /data/local/tmp
#chmod 755 tests
#LD_LIBRARY_PATH=/data/local/tmp:$LD_LIBRARY_PATH ./tests

It seems only LD_LIBRARY_PATH is supported.

I have googled that for java, here are a couple of results
​http://stackoverflow.com/questions/10348305/android-ndk-library-not-found-cannot-link-executable-how-to-set-ld-library-p
​https://developer.android.com/ndk/guides/cpp-support.html (see Shared runtimes and documentation for ​System.load)

BTW, JIC I have also run v8 unittests on that Android, all tests passed.

[sergz]

I have a working version of v8-project and libadblockplus using v8-binaries and I see already that compiling of libadblockplus now is much easier, however now there is a question where can we store these binaries?.
I have configured to build v8 for android_{arm,x86}-release, linux_x64-release and win32_{ia32,x64}-{release,debug}, they occupy a bit less than 1GB and binaries for windows are pretty huge (without pdb files). ​github does not allow to push files bigger than 100MB, as an interim solution I used git-lfs, it works, but how can we use it with our mercurial repository? In addition git-lfs stores files not on our servers (amazon s3).

One can find v8-project here ​https://github.com/abby-sergz/v8-project, currently it allows to build and deploy binaries using appveyour and travis-ci (I have also configurations for libadblockplus). I'm using ​xxxz account on github only for security reasons, if the oauth token somehow leaks.

[eric@adblockplus.org]

FYI.

This item from the Android issue tracker points to a possible resolution of the problem: wait for a release with an adequate version of libc++ (from LLVM).

STLport does not support C++11
​https://code.google.com/p/android/issues/detail?id=216331

The quotation below is an extract from the Release Notes for Android NDK, Revision 13b (October 2016) (taken as of this writing from ​https://developer.android.com/ndk/downloads/index.html but that link is not version-specific).

Announcements

GCC is no longer supported. It will not be removed from the NDK just yet, but is no longer receiving backports. It cannot be removed until after libc++ has become stable enough to be the default, as some parts of gnustl are still incompatible with Clang. It will likely be removed after that point.

NDK

libc++ has been updated to r263688.

[sergz]

Thanks for pointing to it, according to ​change log STLPort is indeed not used since 2016-02-08: Version 4.10.172. Since we don't have anymore MS VS 2010 restriction I will try to update v8 to some decent version and see what it requires.

Just in case, with our current version of v8 as well as with version 4.3.15 (#1197) we cannot simply switch to another library and compiler because v8 is very sensitive to them. Because of that we have to stick to a particular Android NDK versions.

[sergz]

As pointed above STLPort is not used by v8 from #4907, so this issue is not a problem anymore.