How to build V8 for Android armeabi, rather than armeabi-v7a ?

[Robin Watts]

Hi all,

Some background:

I am one of the authors of MuPDF, a cross platform open source PDF viewer. Recently we have been adding support for form filling etc, which requires the use of javascript for validation etc. We've been using v8 (version 3.9) for a while, and it works fine on Windows/MacOS/Linux and Android armeabi-v7a.

We've just had it pointed out to us that it fails on armeabi though - the app falls over trying to load libmupdf.so. This is generated by linking our object files, plus all the static libraries we use (including v8).

The fact it falls over on armeabi is probably not surprising as we currently only have libv8_base.a and libv8_snapshot.a (the v8 libraries we use) built as armeabi-v7a, whereas all the other libraries/files are built for both armeabi and armeabi-v7a.

So I've modified the makefiles to link with different versions of the v8 libs. The problem is, we are still falling over at load time. So it seems likely I've made a mess of building the armeabi v8 libs.

So, The question:

How do I build v8 (preferably version 3.9, but any version would do at this point) for armeabi rather than armeabi-v7a?

On v3.9 I do:

make android                 (to make the armeabi-v7a ones)

make android.clean

make android armv7=0    (to make the armeabi ones)

but they are suspiciously similarly sized.

With the current git HEAD, I had to modify the calls a bit:

For armeabi-v7a I do:

make -j8 GYPFLAGS="-Dcomponent=static_library" android_arm.release

make -j8 GYPFLAGS="-Dcomponent=static_library" android_arm.clean

make -j8 GYPFLAGS="-Dcomponent=static_library" armv7=0 android_arm.release

but again, they are suspiciously similarly sized.

Any help people can give would be much appreciated!

Thanks,

Robin

[Rodolph Perfetta]

Could you give more info on the error you are seeing at load time?

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Robin Watts]

On Monday, 8 April 2013 21:14:04 UTC+1, Rodolph Perfetta wrote:

Could you give more info on the error you are seeing at load time?

Sure. From adb logcat:

 I/ActivityManager(   59): Starting activity: Intent { act=android.intent.action.VIEW dat=/mnt/sdcard/Download/tiger.pdf cmp=com.artifex.mupdfdemo/.MuPDFActivity }

I/System.out(  314): Trying to open /mnt/sdcard/Download/tiger.pdf

D/dalvikvm(  314): Trying to load lib /data/data/com.artifex.mupdfdemo/lib/libmupdf.so 0x44ede358

I/DEBUG   (   31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

I/DEBUG   (   31): Build fingerprint: 'generic/sdk/generic/:2.2/FRF91/43546:eng/test-keys'

I/DEBUG   (   31): pid: 314, tid: 314  >>> com.artifex.mupdfdemo <<<

I/DEBUG   (   31): signal 4 (SIGILL), fault addr 817dda00

I/DEBUG   (   31):  r0 81c8ba50  r1 00000000  r2 817dd9f7  r3 817dd9f5

I/DEBUG   (   31):  r4 81c8ba50  r5 00000005  r6 00000004  r7 00000000

I/DEBUG   (   31):  r8 80813b00  r9 0000ccb0  10 4186bbc0  fp 00000000

I/DEBUG   (   31):  ip a9d000bc  sp beaee778  lr b0001169  pc 817dda00  cpsr 80000030

I/DEBUG   (   31):          #00  pc 007dda00  /data/data/com.artifex.mupdfdemo/lib/libmupdf.so

I/DEBUG   (   31):          #01  lr b0001169  /system/bin/linker

I/DEBUG   (   31):

I/DEBUG   (   31): code around pc:

I/DEBUG   (   31): 817dd9e0 f7ffb508 bd08fe53 1c04b510 e0ecf5a7

I/DEBUG   (   31): 817dd9f0 bd101c20 4c08b510 447c2100 1c203408

I/DEBUG   (   31): 817dda00 e0e8f5a7 49064a05 4479447a 1c206812

I/DEBUG   (   31): 817dda10 e2e4f5a7 46c0bd10 004ae04a 00495c7c

I/DEBUG   (   31): 817dda20 ffffffdb 4647b5f0 4698b480 33581c03

I/DEBUG   (   31):

I/DEBUG   (   31): code around lr:

I/DEBUG   (   31): b0001148 2a002601 1e48d003 18e40083 00b64276

I/DEBUG   (   31): b0001158 e0061c0d 19a46823 32031e5a 4798d800

I/DEBUG   (   31): b0001168 2d003d01 bd70dcf6 1c03b510 1c0433e8

I/DEBUG   (   31): b0001178 28006818 3304d004 22016819 ffdef7ff

I/DEBUG   (   31): b0001188 682334f4 d0002b00 bd104798 47702000

I/DEBUG   (   31):

I/DEBUG   (   31): stack:

I/DEBUG   (   31):     beaee738  811845d8  /data/data/com.artifex.mupdfdemo/lib/libmupdf.so

I/DEBUG   (   31):     beaee73c  00000015

I/DEBUG   (   31):     beaee740  81038a14  /data/data/com.artifex.mupdfdemo/lib/libmupdf.so

I/DEBUG   (   31):     beaee744  b0001599  /system/bin/linker

I/DEBUG   (   31):     beaee748  b00104bc

I/DEBUG   (   31):     beaee74c  00000020

I/DEBUG   (   31):     beaee750  a9d00000  /system/lib/libjnigraphics.so

I/DEBUG   (   31):     beaee754  b00104c4

I/DEBUG   (   31):     beaee758  81c55000  /data/data/com.artifex.mupdfdemo/lib/libmupdf.so

I/DEBUG   (   31):     beaee75c  b0002185  /system/bin/linker

I/DEBUG   (   31):     beaee760  b00103a4

I/DEBUG   (   31):     beaee764  00003890

I/DEBUG   (   31):     beaee768  00006e8f

I/DEBUG   (   31):     beaee76c  8114d168  /data/data/com.artifex.mupdfdemo/lib/libmupdf.so

I/DEBUG   (   31):     beaee770  df002777

I/DEBUG   (   31):     beaee774  e3a070ad

I/DEBUG   (   31): #00 beaee778  81c732a4  /data/data/com.artifex.mupdfdemo/lib/libmupdf.so

I/DEBUG   (   31):     beaee77c  b0001169  /system/bin/linker

I/DEBUG   (   31):     beaee780  b0010488

I/DEBUG   (   31):     beaee784  00002734

I/DEBUG   (   31):     beaee788  b0010494

I/DEBUG   (   31):     beaee78c  b000122b  /system/bin/linker

I/DEBUG   (   31):     beaee790  b00134dc

I/DEBUG   (   31):     beaee794  afd00000  /system/lib/libc.so

I/DEBUG   (   31):     beaee798  00000020

I/DEBUG   (   31):     beaee79c  b00103a4

I/DEBUG   (   31):     beaee7a0  b00103a4

I/DEBUG   (   31):     beaee7a4  00002734

I/DEBUG   (   31):     beaee7a8  00002734

I/DEBUG   (   31):     beaee7ac  b0002817  /system/bin/linker

I/DEBUG   (   31):     beaee7b0  b00103a4

I/DEBUG   (   31):     beaee7b4  00000020

I/DEBUG   (   31):     beaee7b8  81000000  /data/data/com.artifex.mupdfdemo/lib/libmupdf.so

I/DEBUG   (   31):     beaee7bc  b00103ac

D/Zygote  (   33): Process 314 terminated by signal (4)

I/ActivityManager(   59): Process com.artifex.mupdfdemo (pid 314) has died.

I/WindowManager(   59): WIN DEATH: Window{45003c90 com.artifex.mupdfdemo/com.artifex.mupdfdemo.ChoosePDFActivity paused=false}

I/ActivityManager(   59): Start proc com.artifex.mupdfdemo for activity com.artifex.mupdfdemo/.ChoosePDFActivity: pid=322 uid=10036 gids={1015, 3003}

[Rodolph Perfetta]

It doesn't seem to be in V8 generated code so try forcing the build system to target armv5:

export CC=gcc -march=armv5

export CXX=g++ -march=armv5

then your make command

[Robin Watts]

On Tuesday, 9 April 2013 16:46:37 UTC+1, Rodolph Perfetta wrote:

It doesn't seem to be in V8 generated code so try forcing the build system to target armv5:

export CC=gcc -march=armv5

export CXX=g++ -march=armv5

then your make command

Alas, I don't think it's quite that simple. I've spent all day bashing at this and discovered various things:

Firstly, when I compile armeabi code under the NDK it uses "-march=armv5te -mtune=xscale -msoft-float".

When I compile armeabi-v7a code under the NDK it uses "-march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16".

The gyp scripts that generate the makefiles set the options to match the armeabi-v7a, so just setting CC and

CXX as you suggest would not work as the compiler will error out as 2 -march's are given.

So I hacked the gyp scripts to properly generate makefiles with the relevant flags above, rebuilt and... it still

crashes in the same place.

There is a note in this very forum saying that 3.17 is the latest version that will support "older than vfpv2" versions,

so I backtracked to 3.9, applied a similar set of changes to the gyp scripts, regenerated the makefiles and

rebuilt. And it crashes even with that.

So at this point, I'm concluding that there is something fundamental in V8 that means it can't be used successfully

with armeabi phones and we'll just disable the use of js/forms in MuPDF for devices of this vintage.

If someone can prove me wrong, I'd be very grateful!

Thanks,

Robin

[Robin Watts]

And I completely forgot to say in the above - Thanks Rodolph for trying!

[Rodolph Perfetta]

Which CPU are you running the armeabi version on? V8 supports ARMv6 + VFPv2 so it doesn't have to be on v7. If you are looking at pre ARMv6 support then as you said you should disable V8 for this target (v3.9 should work but not future versions).

The trace you sent looks like it maybe an arm/thumb mismatch, you could add -mthumb to the makefile and check.

On 9 April 2013 18:32, Robin Watts <robinw...@googlemail.com> wrote:

And I completely forgot to say in the above - Thanks Rodolph for trying!

[Rodolph Perfetta]

I should probably have asked before, but what makes you think the crash comes from V8? Do you have a more precise trace?

[Robin Watts]

On Tue, Apr 9, 2013 at 8:40 PM, Rodolph Perfetta <rodolph....@gmail.com> wrote:

> Which CPU are you running the armeabi version on?

I'm trying it on a Froyo (armeabi) device set up on the standard android emulator.

> V8 supports ARMv6 + VFPv2 so it doesn't have to be on v7. If you are looking at pre ARMv6 support then

> as you said you should disable V8 for this target (v3.9 should work but not

> future versions).

Right. Ideally it's 3.9 I'd like to make work - but I've had no luck at all.

> The trace you sent looks like it maybe an arm/thumb mismatch, you could add

> -mthumb to the makefile and check.

Alas -mthumb didn't help :(

On Tuesday, 9 April 2013 20:58:30 UTC+1, Rodolph Perfetta wrote:

I should probably have asked before, but what makes you think the crash comes from V8? Do you have a more precise trace?

I can build our library with v8 linked in, or not. The version without v8 linked in works perfectly. The version with v8 dies during the shared library load. This suggests to me that there is some binary incompatibility between the two. I'd *guess* that there is some initialisation code in the v8 lib that is called at load time and that's somehow causing the crash, but the gdb backtrace is the textbook definition of unhelpful.

Thanks again,

Robin

[Robin Watts]

For anyone interested, we've now thrown this open to any interested developer under our Bug Bounty programme - if you think you can get me an armeabi build of v8, then step up and get some cash :)

http://bugs.ghostscript.com/show_bug.cgi?id=693857

Thanks,

Robin