[Ecls-list] porting to android using NDK
Sylvain Ageneau
ageneau at gmail.com
Sun Feb 20 18:41:15 UTC 2011
Thanks for the tip! It turns out the problem had to do with using a 64
bits ECL host to do the cross compilation.
The generated C code is slightly different in that case for example:
diff -Nru build.device.notok//clos/builtin.c
build.device.ok//clos/builtin.c
--- build.device.notok//clos/builtin.c 2011-02-20 13:47:28.000000000
-0300
+++ build.device.ok//clos/builtin.c 2011-02-20 13:16:45.000000000
-0300
@@ -265,7 +265,7 @@
V7= V9;
goto L17;
L19:;
- V7= MAKE_FIXNUM(2305843009213693951);
+ V7= MAKE_FIXNUM(536870911);
}
L17:;
V5= V4;
Is this expected? I assumed that datatype sizes were set properly in the
"cross_config" file, the host datatype sizes shouldn't matter. I have
this in the cross_config file:
CL_FIXNUM_TYPE=int
CL_FIXNUM_BITS=32
CL_FIXNUM_MAX=536870911L
CL_FIXNUM_MIN=-536870912L
CL_INT_BITS=32
CL_LONG_BITS=32
Anyways by compiling a host ECL using: CC="gcc -m32" ABI=32, I could
cross compile a working ECL (haven't done extensive testing but it
passes "cl_boot" successfully).
By the way this issue also happens on iPhone using R. Krishnan's iPhone
build and it can be solved the same way.
I'll try to publish an updated build procedure on github soonish.
On Wed, 2011-02-09 at 21:13 +0100, Juan Jose Garcia-Ripoll wrote:
> I am forwarding an excerpt of a message that was too large for the
> list due to the attachments. The attached tarball, which contains the
> NDK port (wow!) is temporarily found here
> http://bit.ly/e8Wri1
>
>
> I had no time to test this file -- must first find time to download
> the NDK and play with it --, but please interested people have a look
> and report back. My feeling is that some of the cross compiled
> features are not working properly. In particular some datatypes might
> be missing due to a mismatch between the available types in the host
> and in the cross-compiled builds.
>
>
> Best,
>
>
> Juanjo
>
> ---------- Forwarded message ----------
> From: Sylvain Ageneau <ageneau at gmail.com>
> To: ecls-list at lists.sourceforge.net
> Date: Mon, 07 Feb 2011 22:53:09 -0300
> Subject: Re: [Ecls-list] porting to android using NDK
> Hello,
>
> I did some initial work porting ECL to android.
>
> I'm currently at the point where I'm having what seems to be the same
> problem that was reported here (stuck in an infinite loop in
> init_lib_LSP):
> http://www.mail-archive.com/ecls-list@lists.sourceforge.net/msg00744.html.
>
> Apparently the responsible code is compiled
> from ./src/clos/builtin.lsp.
> See backtrace:
>
> #0 0x83829164 in si_memq (x=0x5ffd20, l=0x602e81)
> at /home/sylvain/src/ecl/src/c/list.d:875
> #1 0x8394b730 in si_subclassp (narg=1, V1=0x0, V2=0x5ffd20) at
> lsp/predlib.c:1694
> #2 0x83903034 in L53fast_subtypep (V1=0x5ffd38, V2=0x5ffd20) at
> clos/kernel.c:1348
> #3 0x83903318 in L54compare_specializers (V1=0x5ffd20, V2=0x5ffd38,
> V3=0x5ffd98) at clos/kernel.c:1404
> #4 0x83902da0 in L52compare_specializers_lists (V1=0x604a31,
> V2=0x6044f1, V3=0x607a09) at clos/kernel.c:1286
> #5 0x83902cd0 in L51compare_methods (V1=0x5ff6d8, V2=0x5ff4f8,
> V3=0x607a09, V4=0x1) at clos/kernel.c:1262
> #6 0x83902a90 in L50compute_applicable_methods (V1=0x5ff6f0,
> V2=0x607a21) at clos/kernel.c:1190
> #7 0x83852ba8 in dispatch2 (narg=2, x0=0x5ff6f0, x1=0x607a21)
> at /home/sylvain/src/ecl/src/c/cfun_dispatch.d:24
> #8 0x839772a0 in L15precompute_valid_initarg_keywords (V1=0x5ffd98)
> at
> clos/standard.c:580
> #9 0x83976348 in LC6make_instance (narg=0, V1=0x83a5787c) at
> clos/standard.c:275
> #10 0x8399c2a0 in APPLY (n=7, fn=0x839761a8 <LC6make_instance>,
> x=0x2ad004) at /home/sylvain/src/ecl/src/c/apply.d:32
> #11 0x8382a37c in ecl_apply_from_stack_frame (frame=0xbe9dd820,
> x=0x5ff5e8) at /home/sylvain/src/ecl/src/c/eval.d:54
> #12 0x8382a820 in cl_apply (narg=-2086832780, fun=0x83a50d2c,
> lastarg=0xbe9dd820) at /home/sylvain/src/ecl/src/c/eval.d:138
> #13 0x839d6288 in LC2__g4 (narg=6323321, V1=0x5ff5b8, V2=0xbe9dd820)
> at
> clos/combin.c:125
> #14 0x839d64d0 in LC4__g5 (narg=1, V1=0x83a576fc, V2=0x5b2) at
> clos/combin.c:159
> #15 0x8399c070 in APPLY (n=2, fn=0x839d63ac <LC4__g5>, x=0x42dd2008)
> at /home/sylvain/src/ecl/src/c/apply.d:27
> #16 0x8382a3a0 in ecl_apply_from_stack_frame (frame=0xbe9dd6e0,
> x=0x5ff0f0) at /home/sylvain/src/ecl/src/c/eval.d:56
> #17 0x8382a740 in cl_funcall (narg=1121787912, function=0x5ff5d0)
> at /home/sylvain/src/ecl/src/c/eval.d:129
> #18 0x8383a548 in _ecl_standard_dispatch (frame=0xbe9dd820,
> gf=0x5ff5d0)
> at /home/sylvain/src/ecl/src/c/gfun.d:394
> #19 0x8383a69c in generic_function_dispatch_vararg (narg=-2086307716)
> at /home/sylvain/src/ecl/src/c/gfun.d:408
> #20 0x839d05a8 in _ecl8LKa3G3mvicrW_T6rDuiz (flag=0x3) at
> clos/builtin.c:362
> #21 0x8384df70 in read_VV (block=0x59b740, entry_point=0x839d0390
> <_ecl8LKa3G3mvicrW_T6rDuiz>)
> at /home/sylvain/src/ecl/src/c/read.d:2295
> #22 0x838a6340 in init_lib_LSP (cblock=0x3) at eclinitIhhZid.c:119
> #23 0x8384df70 in read_VV (block=0x59bfc0, entry_point=0x838a5c90
> <init_lib_LSP>) at /home/sylvain/src/ecl/src/c/read.d:2295
> #24 0x8381d934 in cl_boot (argc=1, argv=0xbe9ddba8)
> at /home/sylvain/src/ecl/src/c/main.d:759
> #25 0x8381c734 in ecl_boot (root_dir=0x83a0e2e4 "/")
> at /home/sylvain/workspace/hello-jni/jni/ecl_boot.c:69
> #26 0x8381c63e in Java_com_example_hellojni_HelloJni_startECL
> (env=0xabe0, thiz=0x4051be80)
> at /home/sylvain/workspace/hello-jni/jni/hello-jni.c:62
> #27 0x81d17d38 in ?? ()
>
>
> Some notes about what I tried so far:
> * Started from a recent ecl git
> (e6d180e7df3cbc91be08bb2a3b9793c01468a679)
> * Replace boehm with a recent cvs version. 2 reasons for this:
> 1. The version of boehm shipped with ecl has a problem finding the
> stack
> base which is fixed by using the USE_GET_STACKBASE_FOR_MAIN define
> that
> was added in more recent versions
> 2. Latest boehm seems to have been adapted for android (see
> -DPLATFORM_ANDROID) --> apparently backported from monodroid
> * An ugly hack to load "ucd.dat" from the android assets (can't just
> fopen it because it's compressed in the package that's uploaded to the
> phone)
> * patch ecl + boehm (in attachment)
> * Used the configure_linux script to build the host ECL and
> configure_android to build the cross-compiled ECL
> * tried --enable-threads=no --> same problem as above
> * You can use the included "gdb_wrapper" script to debug ECL from
> emacs
> (you first need to connect using jdb and set an initial breakpoint in
> your .jdbrc, also comment out the line $GDBCLIENT -x `native_path
> $GDBSETUP` from the ndk-gdb script)
> * Instructions to cross-compile are basically the same as for the
> iPhone
> port. See the 2 scripts configure_linux and configure_android
> * Also attaching the sample android project I used. It basically just
> calls "cl_boot"
>
> Any help welcome :)
>
> Cheers,
> Sylvain
>
>
>
>
>
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://juanjose.garciaripoll.googlepages.com
>
>
More information about the ecl-devel
mailing list