Hi Kevin,.
The patch for building through android makefile gyp wrapper is ready. You
can find it on our github repo github.com/paul99/v8m-rb/ on dm-dev branch
until it is not submitted on official v8 repo.
It is based upon current bleeding_edge branch. Alternatively, you can apply
it yourself using diff that is attached.
thank you for reporting this.
On Tuesday, September 4, 2012 11:45:23 PM UTC+2, paul lind wrote:
>
> Hi Kevin -
>
> I'm sorry to say we had missed the updates to the Android makefiles. We
> usually build Android v8 inside the full Android AOSP tree, which probably
> does you no good at all. And it uses a different build system.
>
> We'll work on this, and get you a patch in the next day or two, and get it
> submitted upstream to the v8 team as well.
>
> thanks,
>
> paul
>
>
> On Sep 3, 2012, at 4:37 AM, Kevin Read wrote:
>
> Hi Paul,
>
> thanks for the informative reply.
> How would I go about building v8 for MIPS android? Makefile.android
> doesn't list this combination of flags.
>
> All the best,
>
> Kevin
>
> On 02.09.2012, at 23:15, Paul Lind wrote:
>
> Hi Kevin -
>
> Regarding your MIPS question, you are best off pulling from Google's
> release branches, which match up to major Chrome releases. Those will have
> received the most testing, on all platforms. The latest right now is 3.12,
> and Android Jelly Bean is using 3.9, if that matters to you at all.
>
> As you may or may not know, the MIPS port is developed by our outside
> team, and on any given day we may not have finished porting necessary to
> work with recent changes the Google team has made. Roughly once a week,
> they push to trunk, and we currently don't sync up with them on these
> pushes. So MIPS may be broken in trunk. We definitely do sync up on the
> release branches, and get everything thoroughly tested.
>
> We do keep the code at our own repo (https://github.com/paul99/v8m-rb)
> working and our bleeding_edge branch will match theirs (though possibly a
> day or two behind as port changes). So far there has not been demand for
> keeping 'trunk' in sync for MIPS. But again, our bleeding_edge and theirs
> can be broken at a given moment in time, so release branches are your best
> bet for product development.
>
> I don't know the answer to all your ARM questions, but I do know that Neon
> is not used in v8, however the VFP3 floating point is required for the
> optimizing (crankshaft) compiler.
>
> thanks,
>
> paul
>
>
> On Sep 2, 2012, at 10:55 AM, Kevin Read wrote:
>
> Hi all,
>
> I succeeded in using v8 via JNI and the ndk from within my android app.
> The idea here is to reuse existing JS code but with performance
> improvements. I have some questions regarding the build flags for the
> different architectures.
>
> I was under the impression that v8 builds for ARMv5 by default. Is that
> correct? I also read somewhere that when compiled for ARMv5 v8 would not
> use the JIT and so performance would suffer. In any case, how would I go
> about compiling for ARMv5 or ARMv7 explicitly?
> Would it make sense to compile v8 with softfp and/or neon? I'm working
> with fairly math intensive code.
>
> I would also like to investigate building for MIPS, so that I have all
> tablet hardware covered. Can I use trunk for that at the moment, or should
> I try to work with the code from https://github.com/paul99/v8m-rb/?
>
> Thanks for your input, and for this best of JS VMs :)
>
> Regards,
> Kevin
>
>
> --
> v8-users mailing list
> [email protected] <javascript:>
> http://groups.google.com/group/v8-users
>
>
>
> --
> v8-users mailing list
> [email protected] <javascript:>
> http://groups.google.com/group/v8-users
>
>
>
> --
> v8-users mailing list
> [email protected] <javascript:>
> http://groups.google.com/group/v8-users
>
>
>
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
diff --git a/Makefile b/Makefile
index de7433e..f17994f 100644
--- a/Makefile
+++ b/Makefile
@@ -124,7 +124,7 @@ endif
ARCHES = ia32 x64 arm mipsel
DEFAULT_ARCHES = ia32 x64 arm
MODES = release debug
-ANDROID_ARCHES = android_ia32 android_arm
+ANDROID_ARCHES = android_ia32 android_arm android_mipsel
# List of files that trigger Makefile regeneration:
GYPFILES = build/all.gyp build/common.gypi build/standalone.gypi \
diff --git a/Makefile.android b/Makefile.android
old mode 100644
new mode 100755
index bdbcbb4..2b1b6de
--- a/Makefile.android
+++ b/Makefile.android
@@ -26,7 +26,7 @@
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
# Those definitions should be consistent with the main Makefile
-ANDROID_ARCHES = android_ia32 android_arm
+ANDROID_ARCHES = android_ia32 android_arm android_mipsel
MODES = release debug
# Generates all combinations of ANDROID ARCHES and MODES,
@@ -50,11 +50,17 @@ ifeq ($(ARCH), android_arm)
DEFINES += arm_neon=0 armv7=1
TOOLCHAIN_ARCH = arm-linux-androideabi-4.4.3
else
- ifeq ($(ARCH), android_ia32)
- DEFINES = target_arch=ia32 v8_target_arch=ia32 android_target_arch=x86
- TOOLCHAIN_ARCH = x86-4.4.3
+ ifeq ($(ARCH), android_mipsel)
+ DEFINES = target_arch=mipsel v8_target_arch=mipsel android_target_arch=mips
+ DEFINES += mips_arch_variant=mips32r2
+ TOOLCHAIN_ARCH = mipsel-linux-android-4.4.3
else
- $(error Target architecture "${ARCH}" is not supported)
+ ifeq ($(ARCH), android_ia32)
+ DEFINES = target_arch=ia32 v8_target_arch=ia32 android_target_arch=x86
+ TOOLCHAIN_ARCH = x86-4.4.3
+ else
+ $(error Target architecture "${ARCH}" is not supported)
+ endif
endif
endif
diff --git a/build/android.gypi b/build/android.gypi
old mode 100644
new mode 100755
index c084b63..2553cc9
--- a/build/android.gypi
+++ b/build/android.gypi
@@ -151,6 +151,24 @@
'-mfpu=vfp3',
],
}],
+ ['target_arch=="mipsel"', {
+ 'cflags': [
+ '-EL',
+ ],
+ 'conditions': [
+ ['mips_arch_variant=="mips32r2"', {
+ 'cflags': ['-mips32r2', '-Wa,-mips32r2'],
+ }],
+ ['mips_arch_variant=="loongson"', {
+ 'cflags': ['-mips3', '-Wa,-mips3'],
+ }, {
+ 'cflags': ['-mips32', '-Wa,-mips32'],
+ }],
+ ],
+ 'ldflags': [
+ '-EL',
+ ],
+ }],
# NOTE: The stlport header include paths below are specified in
# cflags rather than include_dirs because they need to come
# after include_dirs. Think of them like system headers, but
@@ -172,6 +190,11 @@
'-L<(android_ndk_root)/sources/cxx-stl/stlport/libs/armeabi',
],
}],
+ ['target_arch=="mipsel"', {
+ 'ldflags': [
+ '-L<(android_ndk_root)/sources/cxx-stl/stlport/libs/mips',
+ ],
+ }],
['target_arch=="ia32"', {
'ldflags': [
'-L<(android_ndk_root)/sources/cxx-stl/stlport/libs/x86',
@@ -188,6 +211,16 @@
'-fno-stack-protector',
],
}],
+ ['target_arch=="mipsel"', {
+ # The mips toolchain currently has problems with stack-protector.
+ 'cflags!': [
+ '-fstack-protector',
+ '-U__linux__'
+ ],
+ 'cflags': [
+ '-fno-stack-protector',
+ ],
+ }],
],
'target_conditions': [
['_type=="executable"', {
