[Ecls-list] porting to android using NDK

Wed Feb 9 20:13:43 UTC 2011

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110209/f005c788/attachment.html>