compiling ecl android on MacOSX

Tue Mar 1 07:22:01 UTC 2016

Pascal J. Bourguignon writes:

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

Congrats :-)
>
>
> [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]$
>

Have you tried just removing the NM from this line?

I think there was some problems while cross-compiling when NM wasn't
explicitly set to nm, I'll investigate it when find some time (added an
issue):

https://gitlab.com/embeddable-common-lisp/ecl/issues/221
>
> 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?

it should, previous paragraph of my answer.
>
>
>> 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.

It's true with GPLv2 and LGPLv2 (it's only about the source). It's the
ECL version. Note, that you'll have to use bundled GMP, which is LGPLv2
as well, because upstream GMP 6.x.x has switched to LGPLv3, which has
anti-tivoization clause, which forbids deploying the software on locked
platforms (ie forbidding their user to modify the source and replace the
binary).
>
> 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)).

I understand your point of view regarding using the Apple devices
(though I disagree with it).
>
> 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.

Thank you for taking time on testing and reporting back the how
everything gone.

Best regards,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Poznań, Poland
TurtleWare - Daniel Kochmański      | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

