v8 cannot be statically linked with libadblockplus for android
|Cc:||fhd, rjeschke, asmirnov, eric@…||Blocked By:|
|Blocking:||#1197, #4453||Platform:||Unknown / Cross platform|
Description (last modified by 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.