On 07/11/15 02:09, Daniel Kochmański wrote:

Dear all,

for the last few weeks I was working on the ECL Android integration. I've managed to create a basic app which is swank-capable. More info here: https://common-lisp.net/project/ecl/

I'll appreciate all the feedback :)

Trying to compile the HEAD (develop, commit 61150e38be5405b8a1c691b6330b473259852b77) of ecl to generate the cross compiler, configure fails:

### YOU ARE TRYING TO CROSS COMPILE ECL. ### PLEASE FOLLOW THESE INSTRUCTIONS: ### ### 1) Vital information cannot be determined at configuration time ### because we are not able to run test programs. A file called ### ### has been created, that you will have to fill out. Please do ### it before invoking "configure" again.

(Notice, no file name indicated),

Pascal J. Bourguignon writes:

(Sorry previous message sent too early, a bug in Thunderbird).

On 07/11/15 02:09, Daniel Kochmański wrote:

...

Dear all,

for the last few weeks I was working on the ECL Android integration. I've managed to create a basic app which is swank-capable. More info here: https://common-lisp.net/project/ecl/

I'll appreciate all the feedback :)

Trying to compile the HEAD (develop, commit 61150e38be5405b8a1c691b6330b473259852b77) of ecl to generate the cross compiler, configure fails:

This is my bad. Branch you want is "mobile" not "develop". I plan to merge it soon.

### YOU ARE TRYING TO CROSS COMPILE ECL.
### PLEASE FOLLOW THESE INSTRUCTIONS:
###
### 1) Vital information cannot be determined at configuration time
### because we are not able to run test programs. A file called
###
### has been created, that you will have to fill out. Please do
### it before invoking "configure" again.

(Notice, no file name indicated).

### 2) To cross-compile ECL so that it runs on the system
###        arm-unknown-linux-androideabi
### you need to first compile ECL on the system in which you are
building
### the cross-compiled files, that is
###        x86_64-apple-darwin15.0.0
### By default we assume that ECL can be accessed from some directory in
### the path.
ECL_TO_RUN=/opt/local/bin/ecl
configure: error: Configuration aborted

This is another typo in README.og (already fixed in repository)

after building host compiler you have to:

export ECL_TO_RUN=`pwd`/android/ecl-32/bin/ecl rm -r build

./configure --host=arm-linux-androideabi \ --prefix=`pwd`/ecl-android \ --with-cross-config=`pwd`/src/util/android.cross_config \ --disable-soname

where `pwd`/android-ecl-32/bin/ecl is path to your host ECL.

I already have /opt/local/bin/ecl, it's provided by MacPorts (version 16.0.0).

OK, no problem with that. Keep in mind though that it has to be 32 bit build with disabled longdouble. It will be changed when cross-compilation framework work is done, but for now you'll probably have to build your local host compiler.

I defined ELC_TO_RUN and relaunched the script, and it's now failing with a failure to configure gmp.

Attached a tarball with logs.

Regards, Daniel

these are my notes on cross compiling ECL from x64 linux to mipsel linux.

first compile a compatible ecl on the host (some config, like word size, must match the target): apt-get install gcc-multilib CFLAGS=-m32 LDFLAGS=-m32 ABI=32 ./configure --prefix=/opt/ecl-host --enable-longdouble=no

then for the target: export STAGING_DIR=/home/alendvai/workspace/lambdanative/OpenWrt-SDK-ar71xx-generic_gcc-4.8-linaro_uClibc-0.9.33.2.Linux-x86_64/staging_dir export TOOLCHAIN=${STAGING_DIR}/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/ export TARGETROOT=${STAGING_DIR}/target-mips_34kc_uClibc-0.9.33.2/

PATH=/opt/ecl-host/bin/:${TOOLCHAIN}/bin:${PATH} \ CFLAGS="-I${TOOLCHAIN}/include -I${TARGETROOT}/usr/include" \ LDFLAGS="--sysroot=${TARGETROOT}" ./configure \ --prefix=/opt/ecl-mips --disable-longdouble \ --with-libffi-prefix=${TARGETROOT} \ --host=mips-openwrt-linux --with-system-gmp

PATH=/opt/ecl-host/bin/:${TOOLCHAIN}/bin:${PATH} make

at first it will fail. create a file build/cross_config, edit it, and invoke the above ./configure again.

HTH,

Daniel Kochmański daniel@turtleware.eu writes:

Hey,

I've noticed in your scripts that you build without the dffi - please try removing this option. It seems unrelated but who knows.

Didn't help.

I can't reproduce your error unfortunately. I have however a suspicion why libtool can't "see" the toolchain in the path.

src/bdwgc/libatomic_ops/configure:7972:LIBTOOL='$(SHELL) $(top_builddir)/libtool'

Probably the PATH variable gets "cleaned" when invoking the shell command and libtool from libatomic_ops can't see the libtool.

Please try remove the invocation of libtool via /bin/sh

src/bdwgc/libatomic_ops/configure:7972:LIBTOOL='$(top_builddir)/libtool'

If it works for you please let me know so I'll fix it in the sourcecode.

Doesn't help.

But I notice an inconsistency in the libtool scripts generated. For example, ecl/build/libffi/libtool contains:

NM="/home/pjb/opt/toolchains/android-arm-ndk-android-18/bin/arm-linux-androideabi-nm -B" OBJDUMP="arm-linux-androideabi-objdump" AR="arm-linux-androideabi-ar" STRIP="arm-linux-androideabi-strip" RANLIB="arm-linux-androideabi-ranlib" LTCC="arm-linux-androideabi-gcc -fPIC" striplib="arm-linux-androideabi-strip --strip-unneeded" LD="/home/pjb/opt/toolchains/android-arm-ndk-android-18/arm-linux-androideabi/bin/ld" CC="arm-linux-androideabi-gcc -fPIC" LD="/home/pjb/opt/toolchains/android-arm-ndk-android-18/arm-linux-androideabi/bin/ld" CC="arm-linux-androideabi-g++"

So, sometimes, there's a full path to the cross compiler tools, and sometimes, there's just the file name.

As bash scripts, they will load /etc/profile and ~/.bash_profile (or else ~/.bash_login or else ~/.profile) and $BASH_ENV; the later will usually set the PATH, overriding the environment.

Since we configure the PATH when compiling (either in a script like my compile-toolchain.sh, or in an interactive shell), this environment variable will usually be overriden when bash scripts such as libtool are started.

If I source my android.sh where the PATH is updated in my $BASH_ENV, then the compilation with the cross compiler proceeds successfully.

[pjb@kuiper :0.0 android]$ file ~/opt/toolchains/android-arm-ecl/bin/ecl /home/pjb/opt/toolchains/android-arm-ecl/bin/ecl: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped

I would therefore advice to either copy the environment PATH in those scripts, or only use absolute path for the cross compiler commands.

On Tue, 10 Nov 2015 03:17:17 +0100 "Pascal J. Bourguignon" pjb@informatimago.com wrote:

I compiled and installed successfully ecl-android on a cyanogen cm-12.1 android on Sansung Galaxy S4.

After getting quicklisp:

• I tried (ql:add-to-init-file) but I'm not sure it was successful, since it waits for a newline input.

• I tried to start swank, either from the menu, or by evaluating (start-swank), but in both case, I got an error (ERROR in eval).

I guess next step will be to integrate with my application, or to improve the user interface for the "ECL Android" app.

I'm not sure if it could be adapted to Android, but I remember there being a GTK ECL SLIME client or IDE, unfortunately I don't remember its name at the moment, but others may remember?

Pascal J. Bourguignon writes:

I compiled and installed successfully ecl-android on a cyanogen cm-12.1 android on Sansung Galaxy S4.

After getting quicklisp:

• I tried (ql:add-to-init-file) but I'm not sure it was successful, since it waits for a newline input.

Init file isn't loaded at start. You may add loading it in user.lisp under

assets/lisp/etc/user.lisp

in ecl-android sources. I'd advise you though to use (get-quicklisp) instead, because it replaces QL minitar and gunzip with precompiled versions (much faster then the bytecompiled ones).

• I tried to start swank, either from the menu, or by evaluating (start-swank), but in both case, I got an error (ERROR in eval).

You should put slime-2.14/ in assets/lisp/home/ . I'll add it to the readme later.

I guess next step will be to integrate with my application, or to improve the user interface for the "ECL Android" app.

I wouldn't recommend integrating ecl-android yet. As mentioned a few times it's an alpha quality and as you have noticed it has many shortcomings. I hope to improve this state soon (after assembling the next ECL Quarterly).

Some notes regarding working with ecl-android: - all lisp files are in assets/lisp/ directory - they are extracted on the first boot of the application, so if you modify for instance user.lisp and install application over the previous installation it won't get updated unless you'll clear the application data - first loaded file is etc/init.lisp, then it's etc/user.lisp, please customize the latter (not the former file) - environment variables: $ROOT points to the toplevel lisp directory (assets/lisp) $ECLDIR never change this ($ROOT/lib) $ETC contains init.lisp, user.lisp ($ROOT/etc) $HOME contains user files ($ROOT/home)

working lisp library maintains two fifos: $ROOT/ecl_output and $ROOT/ecl_input . Input isn't used yet (had some problems with the slime and working stdin) and output is slurped and shown in the APP.

Application has special service (android-specific) which enables two intents: "ENSURE_LISP" and "EVAL" - the latter takes data argument which contains sexp to exec. This part *is* prone to change. You may export this service to the other applications by modifying AndroidManifest.xml (that means that you will be able to call lisp from application which isn't derivered from ecl-android).

Best regards, Daniel