Hello,
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?
Well, configure passes, but then:
;;; Invoking external command: ;;; arm-linux-androideabi-gcc -I. -I/Users/pjb/src/android/ecl/build/ -DECL_API -I/Users/pjb/src/android/ecl/build/c -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 -Dandroid -I/Users/pjb/src/android/ecl/src/c -c lsp/predlib.c -o lsp/predlib.o In file included from ./ecl/ecl.h:82:0, from ./ecl/ecl-cmp.h:29, from lsp/predlib.c:3: lsp/predlib.c: In function 'si_long_float_p': lsp/predlib.c:1067:42: error: 't_longfloat' undeclared (first use in this function) value0 = ecl_make_bool(type_of(v1x) == t_longfloat); ^ ./ecl/object.h:126:28: note: in definition of macro 'ecl_make_bool' #define ecl_make_bool(x) ((x)? ECL_T : ECL_NIL) ^ lsp/predlib.c:1067:42: note: each undeclared identifier is reported only once for each function it appears in value0 = ecl_make_bool(type_of(v1x) == t_longfloat); ^ ./ecl/object.h:126:28: note: in definition of macro 'ecl_make_bool' #define ecl_make_bool(x) ((x)? ECL_T : ECL_NIL) ^ lsp/predlib.c: In function 'cl_coerce': lsp/predlib.c:2194:14: warning: assignment makes pointer from integer without a cast [enabled by default] value0 = ecl_make_long_float(ecl_to_long_double(v12c__value)); ^
It seems :long-float is put on *feature* when it should not.
It should also be noted that Android is transitionning to 64-bit too, (and iOS already only accepts applications in the AppStore only if they include 64-bit binaries).
https://source.android.com/source/64-bit-builds.html
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).
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..
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).
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.
Pascal J. Bourguignon writes:
Hello,
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?
Well, configure passes, but then:
;;; Invoking external command: ;;; arm-linux-androideabi-gcc -I. -I/Users/pjb/src/android/ecl/build/ -DECL_API -I/Users/pjb/src/android/ecl/build/c -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 -Dandroid -I/Users/pjb/src/android/ecl/src/c -c lsp/predlib.c -o lsp/predlib.o In file included from ./ecl/ecl.h:82:0, from ./ecl/ecl-cmp.h:29, from lsp/predlib.c:3: lsp/predlib.c: In function 'si_long_float_p': lsp/predlib.c:1067:42: error: 't_longfloat' undeclared (first use in this function) value0 = ecl_make_bool(type_of(v1x) == t_longfloat); ^ ./ecl/object.h:126:28: note: in definition of macro 'ecl_make_bool' #define ecl_make_bool(x) ((x)? ECL_T : ECL_NIL) ^ lsp/predlib.c:1067:42: note: each undeclared identifier is reported only once for each function it appears in value0 = ecl_make_bool(type_of(v1x) == t_longfloat); ^ ./ecl/object.h:126:28: note: in definition of macro 'ecl_make_bool' #define ecl_make_bool(x) ((x)? ECL_T : ECL_NIL) ^ lsp/predlib.c: In function 'cl_coerce': lsp/predlib.c:2194:14: warning: assignment makes pointer from integer without a cast [enabled by default] value0 = ecl_make_long_float(ecl_to_long_double(v12c__value)); ^
It seems :long-float is put on *feature* when it should not.
It should also be noted that Android is transitionning to 64-bit too, (and iOS already only accepts applications in the AppStore only if they include 64-bit binaries).
Summary: success compiling ecl-android on MacOSX with the above script, and the indicated patch to ecl/src/configure.
[pjb@larissa :0.0 android]$ cd ecl/ [pjb@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@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@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@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@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@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 writes:
Summary: success compiling ecl-android on MacOSX with the above script, and the indicated patch to ecl/src/configure.
Congrats :-)
[pjb@larissa :0.0 android]$ cd ecl/ [pjb@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/configureno changes added to commit (use "git add" and/or "git commit -a") [pjb@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@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@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@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@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 -
Pascal J. Bourguignon