compiling ecl android on MacOSX

Pascal J. Bourguignon pjb at
Mon Feb 29 23:14:23 UTC 2016

Summary: success compiling ecl-android on MacOSX with the above script, 
and the indicated patch to ecl/src/configure.

[pjb at larissa :0.0 android]$ cd ecl/
[pjb at larissa :0.0 ecl]$ git status
On branch 16.1.2-rc
Your branch is up-to-date with 'origin/16.1.2-rc'.
Changes not staged for commit:
   (use "git add <file>..." to update what will be committed)
   (use "git checkout -- <file>..." to discard changes in working directory)

     modified:   src/configure

no changes added to commit (use "git add" and/or "git commit -a")
[pjb at larissa :0.0 ecl]$ git diff
diff --git a/src/configure b/src/configure
index f151f8d..fed3ed3 100755
--- a/src/configure
+++ b/src/configure
@@ -5628,7 +5628,8 @@ $as_echo "$as_me: Configuring included GMP 
library:" >&6;}
    mkdir gmp
      (destdir=`${PWDCMD}`; cd gmp && CC="${CC} ${PICFLAG}" \
-     NM=nm $srcdir/gmp/configure --disable-shared --prefix=${destdir} \
+ NM=$PLATFORM_PREFIX/bin/arm-linux-androideabi-nm \
+                                      $srcdir/gmp/configure 
--disable-shared --prefix=${destdir} \
       -infodir=${destdir}/doc --includedir=${destdir}/ecl --with-pic \
       --libdir=${destdir} --build=${gmp_build} --host=${host_alias} \
CC="${CC} ${PICFLAG}" \
[pjb at larissa :0.0 ecl]$

On 29/02/16 07:30, Daniel Kochmański wrote:

>> We cannot compile ecl for android on MacOSX, because *nm* is used by gmp
>> configure instead of
>> $PLATFORM_PREFIX/bin/arm-linux-androideabi-nm
>> With NM=$PLATFORM_PREFIX/bin/arm-linux-androideabi-nm  in
>> ecl/src/configure:5630, it passes:
>> checking how to define a 32-bit word... .long
>> but I'm not sure it's correct to hard wire this NM in ecl/src/configure;
>> isn't it generated from
>> autoconf?

> Hello,
> Did you follow the instructions in INSTALL file? First you have to build
> the host ECL (32 bit), and after that the android one withe the provided
> cross-config.
> ./configure ABI=32 CFLAGS="-m32 -g -O2" LDFLAGS="-m32 -g -O2" \
>              --prefix=`pwd`/ecl-android-host \
>              --disable-longdouble \
>              --enable-libatomic=included
> Etc. Building for 64 bit should be also possible with some tweaking of
> cross config in src/util and configure options.
> Mentioned instructions are available here:
> (and
> in the source repository).
Yes, I follow those instructions, in the attached script to make sure 
they're always followed :-)

Clearly, using NM=nm in the cross-compilation is bound to fail, notably 
on MacOSX, where nm, is MachO nm, not elf nm. Ie. it's not a mere 
processor cross-compilation, keeping the rest of the system (linux) and 
file formats constant, but it's a cross-compilation on x86_64 MacOSX 
(Darwin (BSD) system, Mach kernel), with different host file formats 
(MachO), targetting ARM Android (Linux system), with elf file formats.

So you definitely need to use the target platform nm, 
$PLATFORM_PREFIX/bin/arm-linux-androideabi-nm, to look into the target 
object files.

> If these remarks doesn't help please send more details about build
> process you do, host gcc, config.log's, configure options, git commit
> etc. I'll try to help then.
> Please also note, that android support isn't official yet (I'm
> publishing a new release today though 16.1.2, where it already is).
Of course, that's why we're here to debug the build process.

Hey! Miracle!  When I'm extra careful at producing logs with a 
reproducible script, it eventually compiles to completion on MacOSX:

[pjb at larissa :0.0 android]$ file 
/Users/pjb/opt/toolchains/ecl-android/bin/ecl: ELF 32-bit LSB 
executable, ARM, version 1 (SYSV), dynamically linked (uses shared 
libs), not stripped
[pjb at larissa :0.0 android]$ file 
/Users/pjb/opt/toolchains/ecl-android/lib/ ELF 32-bit LSB 
shared object, ARM, version 1 (SYSV), dynamically linked (uses shared 
libs), not stripped
[pjb at larissa :0.0 android]$

I was missing a rm -rf build, and I had tried gmp-6.1.0, which I was 
able to configure successfully, but it seems it had some problems downhill.

> Does appstore accept lgpl apps? As far as I understand it doesn't allow
> dynamic linkage and static linking will result in covering by lgpl also
> your ios app..

Actualy, from iOS 8.0, we can package dynamically linked libraries into 
frameworks that are codesigned and embedded within the application 
package.  I've verified that technically, those shared libraries can 
even be loaded and linked at run-time (with dlopen, dlsym, etc).

In the set of rules for admission in the AppStore, the only rules 
vaguely concerned with this matter only reject code (in whatever form, 
binary or source), downloaded from the Internet.

As long as those dynamically linked frameworks  are codesigned and 
embedded in the application package, and therefore available to Apple to 
be examined for admission to the AppStore, it seems to be ok.

(I've not tried it, but perhaps it would even be possible technically, 
if we're able to embed in an application the code signature tool (and 
required certificates), to generate at run-time a dynlib and code sign 
it, to dynamically load it; I assume the kernel checks that the dynamic 
library is code signed with the same signature as the application that 
is loading it, but it's possible that it doesn't restrict the exact 
location of the library as long as it's in the application package.  Of 
course, such a run-time code generation would be pushing the limits of 
the rules established by Apple, such an application would most probably 
not pass the AppStore gate.  In any case, let's remember fork(1) is 
disabled on iOS, so we couldn't call external tools such as gcc to 
produce those dynamic libraries or codesign(1) to sign them.  Everything 
would have to be done within the application.)

Now, from the point of view of the LGPL (or GPL if it was the case), the 
license doesn't require that the distributor give access to the 
distribution medium used to provide the binaries to the beneficiaries of 
those licenses.  Only that he gives them access to the sources and the 
freedoms afforded by the license.

IANAL, but in my understanding, distribution thru the AppStore is a 
contract between the author of the derived (or original) work, and 
Apple, and this contract remains independent from the contract between 
the author of the derived (or original) work, and the recipient of the 
LGPL or GPL: as long as customers or users of GPL'ed iOS applications 
can obtain the sources, or of LGPL'ed iOS applications can obtain the 
sources of the libraries, and the object files of the rest of the 
application (and associated "makefile", eg. Xcode projects), they are 
able to build (with Xcode, or even with GCC) their own binaries or 
modified binaries, and they can give or sell the results to their own 
friends and customers.  Most probably, they won't be able to get a 
distribution contract thru the AppStore from Apple (since Apple 
explicitely exclude duplicate or similar applications from the 
AppStore).  But this is of no concern to the GPL or LGPL, all the terms 
of which having been respected irregardingly of Apple and its AppStore.

The problem would be more with the technical and social difficulties to 
install applications on iOS devices without going thru the AppStore.  
However, there is a non-Apple MacOSX tool to install iOS applications on 
the iOS (, and while written 
using Apple's frameworks, notably MobileDevice.framework, nothing 
prevents anybody to reverse engineer it and to implement it on a free 
system.  You would still need to obtain a certificate to be able to 
codesign your binaries before installing them on iOS. Certificates can 
be obtained for free from Apple ("Sign in with Apple ID"), for 
installation one's "test device".

ie. basically iOS devices are freedom-privative devices that prevent the 
distribution and installation of binaries obtained from people who are 
not paying the Apple tax (I mean, and up-to-date paid membership to one 
of the tree Apple Developer Programs).

But the fact that a person is already using a iOS device is evidence 
that he has renounced to this freedom, so he cannot hold it against GPL 
or LGPL software providers.

This is really a question that goes beyond the problem of licenses, and 
that the FSF addresses,  and that the society at large should become 
conscious of and address.  Basically, that iOS restrictions (and I would 
say codesigning in general, both for software and for hardware/firmware) 
are a scandal and should be forbidden, IMO.  But given that corporations 
and banksters are the bosses and politicians are whores, I don't know 
what else we can do than to have the fortitude not to buy and use those 
devices. (Sorry, I don't, I have Apple devices and work professionally 
with them: too many customers for iOS apps, to few (read, none) for 
Linux apps (let alone CL)).

> Best regards,
> Daniel
> PS. I've wrote yesterday from my phone, but I'm not sure if it send the
> email properly, sorry for reposting if that's a case.
Seems to be good.

__Pascal J. Bourguignon__

-------------- next part --------------
set -e



export PLATFORM_PREFIX="$TOOLCHAINS/android-ndk18-arm"
export NDK_PATH="$HOME/opt/android-ndk"
export NDK_PLATFORM=android-4

function banner_phase(){
    printf "\n###\n"
    for line ; do
        printf "### %s\n" "$line"
    printf "###\n\n"

function echodo(){
    printf "\n;; "
    echo "$@"
    printf "\n"

echodo mkdir -p "$SRC"
echodo cd "$SRC"

if [ $start -le 0 ] ; then
    echodo rm -rf ecl
    echodo git checkout
    echodo cd ecl
    echodo git checkout -b 16.1.2-rc origin/16.1.2-rc

echodo cd "$SRC/ecl"

if [ $start -le 1 ] ; then
    banner_phase "1. Build the host ECL"

    echodo rm -rf build
    echodo ./configure \
           ABI=32 CFLAGS="-m32 -g -O2" LDFLAGS="-m32 -g -O2" \
           --prefix="$ECL_ANDROID_HOST" \
           --disable-longdouble \
    echodo make -j9
    echodo make install
    echodo rm -r build


export ECL_TO_RUN="$ECL_ANDROID_HOST/bin/ecl"

if [ $start -le 2 ] ; then
    banner_phase "2. Build the toolchain (requires android-ndk) and export the"\
     "necessary paths - if you have a toolchain for the android just"\
     "export its bin/ directory."

    echodo mkdir -p "${PLATFORM_PREFIX}"
    echodo "${NDK_PATH}"/build/tools/ \
               --platform="${NDK_PLATFORM}" \
               --install-dir="${PLATFORM_PREFIX}" \


export PATH="${PLATFORM_PREFIX}/bin:${PATH}"

if [ $start -le 3 ] ; then
    banner_phase "3. Build and install the target library."

    echodo rm -rf build
    echodo ./configure \
           --host=arm-linux-androideabi \
           --prefix="$ECL_ANDROID" \
           --with-cross-config="$(pwd)"/src/util/android.cross_config \
    echodo make -j9
    echodo make install


-------------- next part --------------
A non-text attachment was scrubbed...
Name: compile-ecl-for-android.log.gz
Type: application/x-gzip
Size: 222962 bytes
Desc: not available
URL: <>

More information about the ecl-devel mailing list