[ecl-android v0.0.1]

List overview All Threads
Download

newer

older

ffi:defcallback with cxx

ECL & IPhone Port

Daniel Kochmański

6 Nov 2015 6 Nov '15

8:09 p.m.

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 :)

Regards, Daniel

-- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi

Show replies by date

Pascal J. Bourguignon

7 Nov 7 Nov

4:07 a.m.

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__ http://www.informatimago.com/

Pascal J. Bourguignon

4:14 a.m.

(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:

(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

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

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.

-- __Pascal J. Bourguignon__ http://www.informatimago.com/

Daniel Kochmański

4:55 a.m.

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

-- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi

Pascal J. Bourguignon

9 Nov 9 Nov

11:59 a.m.

Ok, I switched to Linux (GNU/Linux debian 8.1 jessie to be exact), since it seems it's not possible to compile the cross ecl on MacOSX.

But despite having a cross gcc correctly installed, when compiling the cross ecl, some libtool script cannot find it:

libtool: compile: arm-linux-androideabi-gcc -fPIC -DHAVE_CONFIG_H -I../src -I/home/pjb/src/android/ecl/src/bdwgc/libatomic_ops/src -fPIC -Wall -Wextra -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DANDROID -DPLATFORM_ANDROID -DUSE_GET_STACKBASE_FOR_MAIN -DIGNORE_DYNAMIC_LOADING -DAO_REQUIRE_CAS -g -O2 -fPIC -D_THREAD_SAFE -MT atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c /home/pjb/src/android/ecl/src/bdwgc/libatomic_ops/src/atomic_ops.c -fPIC -DPIC -o atomic_ops.o ../libtool: line 1749: arm-linux-androideabi-gcc: command not found Makefile:597: recipe for target 'atomic_ops.lo' failed

See the end of log.txt in the attached archive.

-- __Pascal J. Bourguignon__ http://www.informatimago.com/

Attila Lendvai

12:38 p.m.

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,

-- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The great enemy of clear language is insincerity. When there is a gap between one’s real and one’s declared aims, one turns as it were instinctively to long words and exhausted idioms, like a cuttlefish spurting out ink.” — George Orwell (1903–1950)

Daniel Kochmański

12:53 p.m.

Hey,

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

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.

Regrads, Daniel

Pascal J. Bourguignon writes:

...

Ok, I switched to Linux (GNU/Linux debian 8.1 jessie to be exact), since it seems it's not possible to compile the cross ecl on MacOSX.

But despite having a cross gcc correctly installed, when compiling the cross ecl, some libtool script cannot find it:
libtool: compile:  arm-linux-androideabi-gcc -fPIC -DHAVE_CONFIG_H
-I../src -I/home/pjb/src/android/ecl/src/bdwgc/libatomic_ops/src
-fPIC -Wall -Wextra -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DANDROID
-DPLATFORM_ANDROID -DUSE_GET_STACKBASE_FOR_MAIN
-DIGNORE_DYNAMIC_LOADING -DAO_REQUIRE_CAS -g -O2 -fPIC
-D_THREAD_SAFE -MT atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c
/home/pjb/src/android/ecl/src/bdwgc/libatomic_ops/src/atomic_ops.c
-fPIC -DPIC -o atomic_ops.o
../libtool: line 1749: arm-linux-androideabi-gcc: command not found
Makefile:597: recipe for target 'atomic_ops.lo' failed
See the end of log.txt in the attached archive.

-- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi

Pascal J. Bourguignon

8:32 p.m.

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.

-- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Pascal J. Bourguignon

9:17 p.m.

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.

Matthew Mondor

10:05 p.m.

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?

-- Matt

Daniel Kochmański

10 Nov 10 Nov

2:19 a.m.

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

-- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi

Attila Lendvai

7:44 a.m.

...

intents: "ENSURE_LISP" and "EVAL" - the latter takes data argument which

assuming that these are globals in the android universe, then maybe ENSURE_COMMON_LISP and EVAL_COMMON_LISP?

great news BTW, thanks for the efforts!

-- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “I've never been able to figure out for _whom_ we're saving the irreplaceable resources. If _we_ aren't allowed to use them, then the next generation shouldn't use them either, nor the one after that.” — Harry Browne (1933–2006), 'How I Found Freedom in an Unfree World'

Daniel Kochmański

2:05 a.m.

Pascal J. Bourguignon writes:

...

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.

Thanks. I'll take a look on that when find some time. Grats :)

Daniel

-- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi

3182

Age (days ago)

3185

Last active (days ago)

ecl-devel@common-lisp.net

12 comments

4 participants

tags (0)

participants (4)

Attila Lendvai
Daniel Kochmański
Matthew Mondor
Pascal J. Bourguignon