compiling ecl android on MacOSX
Pascal J. Bourguignon
pjb at informatimago.com
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;}
fi
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} \
CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS" CPPFLAGS="$CPPFLAGS"
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:
> https://gitlab.com/embeddable-common-lisp/ecl/blob/develop/INSTALL (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
/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/libecl.so
/Users/pjb/opt/toolchains/ecl-android/lib/libecl.so: 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 (https://github.com/phonegap/ios-deploy), 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)).
https://developer.apple.com/support/compare-memberships/
https://www.fsf.org/campaigns/iphone
https://www.fsf.org/campaigns/apple
> 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__
http://www.informatimago.com/
-------------- next part --------------
#!/bin/bash
set -e
start=3
SRC="$HOME/src/android"
TOOLCHAINS="$HOME/opt/toolchains"
ECL_ANDROID_HOST="$TOOLCHAINS/ecl-android-host"
ECL_ANDROID="$TOOLCHAINS/ecl-android"
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"
done
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 https://gitlab.com/embeddable-common-lisp/ecl.git
echodo cd ecl
echodo git checkout -b 16.1.2-rc origin/16.1.2-rc
fi
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 \
--enable-libatomic=included
echodo make -j9
echodo make install
echodo rm -r build
fi
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/make-standalone-toolchain.sh \
--platform="${NDK_PLATFORM}" \
--install-dir="${PLATFORM_PREFIX}" \
--arch=arm
fi
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 \
--disable-soname
echodo make -j9
echodo make install
fi
echo "$ECL_ANDROID"
-------------- 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: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20160301/af31dd9f/attachment-0001.bin>
More information about the ecl-devel
mailing list