[Android] For shared library build, use shared versions of stlport and gnu_stl

[Android] For shared library build, use shared versions of stlport and gnu_stl


BUG=158821
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=168606

[Yaron, 2012-11-02 02:35:32]

This gets the build past base and icu and onto failures at v8 and skia.

[nilesh, 2012-11-06 18:37:04]

http://codereview.chromium.org/11312056/diff/1/build/common.gypi
File build/common.gypi (right):

http://codereview.chromium.org/11312056/diff/1/build/common.gypi#newcode2707
build/common.gypi:2707: ['component=="shared_library" and
use_system_stlport==0', {
I think this should go as a condition in the rule above. That way it will not
depend on the order of these rules.

[Yaron, 2012-11-19 18:28:33]

ptal

[nilesh, 2012-11-19 19:06:02]

LGTM

[commit-bot: I haz the power, 2012-11-19 19:08:30]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yfriedman@chromium.org/11312056/6001

[commit-bot: I haz the power, 2012-11-19 21:19:07]

Change committed as 168606

[digit1, 2012-11-20 20:33:19]

https://codereview.chromium.org/11312056/diff/6001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/11312056/diff/6001/build/common.gypi#newcode2890
build/common.gypi:2890: '-lgnustl_shared',
sorry, didn't catch that earlier, but it's probably a bad idea to link to both
stlport and gnu libstdc++ at the same time. Is this really necesssary? Since
you're not adding the include paths to the gnustl headers to the gyp files, I
assume this is not.

[Yaron, 2012-11-21 02:58:30]

https://codereview.chromium.org/11312056/diff/6001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/11312056/diff/6001/build/common.gypi#newcode2890
build/common.gypi:2890: '-lgnustl_shared',
On 2012/11/20 20:33:19, digit1 wrote:
> sorry, didn't catch that earlier, but it's probably a bad idea to link to both
> stlport and gnu libstdc++ at the same time. Is this really necesssary? Since
> you're not adding the include paths to the gnustl headers to the gyp files, I
> assume this is not.

Probably true but since this is just in bring-up phase, I was going to see if it
caused issues down the line. For now, it appears to be needed for shared library
build at link time because of some missing symbols in icui18n:

third_party/android_tools/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6.x-google/../../../../arm-linux-androideabi/bin/ld.gold:
obj/third_party/icu/source/i18n/icui18n.ucal.o: in function
ucal_setGregorianChange_46:../../third_party/icu/source/i18n/ucal.cpp:254:
error: undefined reference to '__cxa_bad_typeid'
third_party/android_tools/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6.x-google/../../../../arm-linux-androideabi/bin/ld.gold:
obj/third_party/icu/source/i18n/icui18n.ucal.o: in function
ucal_getGregorianChange_46:../../third_party/icu/source/i18n/ucal.cpp:270:
error: undefined reference to '__cxa_bad_typeid'

I suspect that since libchromeview.so doesn't have issues normally, that the
linker is optimizing out the code that refers to this. So I'll probably have to
spend more time spelunking in icu.