Script to build ECL for iOS using XCode 10 tools?
Hi, I've been searching for a more recent version of this script: https://github.com/cbbaker/ecl-iphone-builder/blob/master/build.sh but without success. Does anyone reading this have a version sitting around which would work with current Xcode 10, that is: compile ECL for iOS using the clang compiler and targeting the arm64 architecture? Thanks, Paul P.S. The premium could be a port of the 'CL REPL' app from android to the iPhone, if I get it to work, sometime in the near future.
On 9/6/19, PR <polos.ruetz@gmail.com> wrote:
Does anyone reading this have a version sitting around which would work with current Xcode 10, that is: compile ECL for iOS using the clang compiler and targeting the arm64 architecture?
never mind, asking around helped (this branch is not cleaned-up, as the author says, but surely a very good start for somebody willing to pick up from there): https://gitlab.com/embeddable-common-lisp/ecl/blob/arm64-port/ios_build.md
On 9/9/19, PR <polos.ruetz@gmail.com> wrote:
never mind, asking around helped (this branch is not cleaned-up, as the author says, but surely a very good start for somebody willing to pick up from there):
https://gitlab.com/embeddable-common-lisp/ecl/blob/arm64-port/ios_build.md
ok, so having a working build script for ECL on iOS arm64 is a big step forward, but still not enough: I have no problem compiling and deploying the "arm64-port" branch with the following versions: Xcode 10.2 iOS 12 (phone) But it crashes with EXC_BAD_ACCESS during cl_boot(). I can't currently be precise about the point/function it crashes, because this depends on what I put in the main() function: if I add some arbitrary stack variable before cl_boot(), like: char tmp[256]; cl_boot(1, argv); it crashes at a completely different point than without it, the same if I simply change the size of the char vector. The author of the above branch was able to run it successfully about 3 years ago (2016), even with ASDF and Swank, on a real device. Now my question is: if you tried it, and it worked for you, what were the exact Xcode and iOS versions you used? Thanks, Paul
Even of the crash might happen at seemingly random places with a bit of luck a backtrace might provide a hint to the one who know all the inner workings of the program. For example it can tell how far the program came, perhaps accidentally, and how far it didn't come. Additionally to the place where the program crashed ima backtrace often tells where an wrong parameter to a function comes from. Would it be possible for you to provide backtraces for a few different crashes? With a bit of luck someone can use them to find a trivial fix for the current and maybe even many upcoming Os and Toolchain versions. Thanks a lot, and Kind regards, Gunter. On 18 September 2019 22:57:32 CEST, PR <polos.ruetz@gmail.com> wrote:
On 9/9/19, PR <polos.ruetz@gmail.com> wrote:
never mind, asking around helped (this branch is not cleaned-up, as the author says, but surely a very good start for somebody willing to pick up from there):
https://gitlab.com/embeddable-common-lisp/ecl/blob/arm64-port/ios_build.md
ok, so having a working build script for ECL on iOS arm64 is a big step forward, but still not enough: I have no problem compiling and deploying the "arm64-port" branch with the following versions:
Xcode 10.2 iOS 12 (phone)
But it crashes with EXC_BAD_ACCESS during cl_boot(). I can't currently be precise about the point/function it crashes, because this depends on what I put in the main() function: if I add some arbitrary stack variable before cl_boot(), like:
char tmp[256]; cl_boot(1, argv);
it crashes at a completely different point than without it, the same if I simply change the size of the char vector. The author of the above branch was able to run it successfully about 3 years ago (2016), even with ASDF and Swank, on a real device.
Now my question is: if you tried it, and it worked for you, what were the exact Xcode and iOS versions you used?
Thanks,
Paul
-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
On 9/18/19, Gunter Königsmann <gunter@peterpall.de> wrote:
Would it be possible for you to provide backtraces for a few different crashes?
Thanks for your input, now let me explain better: A few days ago I tested with a little different configuration, and the backtrace was just a few frames. Some 'cl_object' pointer had a too low address, and this caused an EXC_BAD_ACCESS some frame after function 'si_pathname_translations()'. What currently happens (witch Xcode 10.2 and the exact same 'arm64-port' branch as on gitlab) is that the backtrace is very long, always exactly 6780 frames; I thought of a blown stack, and didn't look at the highest frames, which indeed point always to the same function; the error condition happens (as above) inside of function 'si_pathname_translations()'. Attached you find the full backtrace; at the end I added a short lldb session, printing some variables. Here the most interesting lines from the lldb session: frame #6777: 0x0000000100cd6c88 repl`si_pathname_translations(narg=2, host=0x000000010250bfc0) at pathname.d:1555:34 1552 for (l = set, set = ECL_NIL; !ecl_endp(l); l = CDR(l)) { 1553 cl_object item = CAR(l); 1554 cl_object from = coerce_to_from_pathname(cl_car(item), host); -> 1555 cl_object to = cl_pathname(cl_cadr(item)); 1556 set = CONS(CONS(from, CONS(to, ECL_NIL)), set); 1557 } 1558 set = cl_nreverse(set); (lldb) print item (cl_object) $0 = 0x00000001013c1931 (lldb) print from (cl_object) $1 = 0x00000000000000db (lldb) print to (cl_object) $2 = 0x0000000100f08a98 As you can see, the value of the 'from' pointer is way too low for a valid 'cl_object' pointer address. (to be continued...)
On 9/19/19, PR <polos.ruetz@gmail.com> wrote:
On 9/18/19, Gunter Königsmann <gunter@peterpall.de> wrote:
Would it be possible for you to provide backtraces for a few different crashes? (to be continued...)
Here another backtrace. I just commented out the following lines in 'cl_boot' (on the desktop I discovered that they are not necessary for simply starting up ECL): file 'src/c/main.d', lines 672-678: /* * Initialize logical pathname translations. This must come after * the character database has been filled. */ //@si::pathname-translations(2,str_sys, // ecl_list1(cl_list(2,str_star_dot_star, // str_rel_star_dot_star))); Now the backtrace is only 12 frames long (see attachment). Still no clue what's going on...
Dear Paul, unfortunately, I don't have time at the moment to look at this in detail, however already from the second backtrace of yours I see that something is missing. Between frame #4: 0x0000000100437940 repl`cl_M(narg=1, num=0x0000000000000001) at minus.d:26:23 and frame #5: 0x000000010052cc44 repl`::_ecllqJxvfb7_PZJOlV41(flag=0x0000000000000000) at numlib.cxx:882:10 I would have expected to see a call to the dispatch_variadic_1 function. Can you please confirm that USE_C_COMPATIBLE_VARIADIC_DISPATCH is defined while compiling src/c/cfun.d, e.g. by inserting #ifndef USE_C_COMPATIBLE_VARIADIC_DISPATCH #error "undefined" #endif in the file and recompiling and that (ECL_SYM("-",17)->symbol.gfdef)->cfun.entry points to the dispatch_variadic_1 function? All the stuff below that in the backtrace is not relevant. Best regards, Marius Am 20.09.19 um 11:08 schrieb PR:
On 9/19/19, PR <polos.ruetz@gmail.com> wrote:
On 9/18/19, Gunter Königsmann <gunter@peterpall.de> wrote:
Would it be possible for you to provide backtraces for a few different crashes? (to be continued...)
Here another backtrace. I just commented out the following lines in 'cl_boot' (on the desktop I discovered that they are not necessary for simply starting up ECL):
file 'src/c/main.d', lines 672-678:
/* * Initialize logical pathname translations. This must come after * the character database has been filled. */ //@si::pathname-translations(2,str_sys, // ecl_list1(cl_list(2,str_star_dot_star, // str_rel_star_dot_star)));
Now the backtrace is only 12 frames long (see attachment). Still no clue what's going on...
On 9/21/19, Marius Gerbershagen <marius.gerbershagen@gmail.com> wrote:
Can you please confirm that USE_C_COMPATIBLE_VARIADIC_DISPATCH is defined while compiling src/c/cfun.d, e.g. by inserting
#ifndef USE_C_COMPATIBLE_VARIADIC_DISPATCH #error "undefined" #endif
Many thanks Marius, your insight helped a lot! The variadic dispatch you mentioned is indeed not defined, which is strange, because I checked if __arm64__ is defined, and it is! (BTW, __arm__ is not defined). So, USE_C_COMPATIBLE_VARIADIC_DISPATCH should be defined too, according to these lines in 'src/c/internal.h': #if defined (__arm__) || defined (__arm64__) #define USE_UNIFIED_ARGS_PASSING_APPLY #define USE_C_COMPATIBLE_VARIADIC_DISPATCH #endif Now, what I did to force variadic dispatching is just commenting out all occurencies of #if defined (USE_C_COMPATIBLE_VARIADIC_DISPATCH) in the 3 files where I found them, and it worked! 'cl_boot' now finishes without errors, and a simple 'cl_print' after 'cl_boot' worked too. (I also uncommented the 3 lines in 'main.d' which caused the initial crash, and those also work fine now.) What remains is to find the reason why USE_C_COMPATIBLE_VARIADIC_DISPATCH is not defined as it should be. Thanks again for your help! Paul
On 9/23/19, PR <polos.ruetz@gmail.com> wrote:
On 9/21/19, Marius Gerbershagen <marius.gerbershagen@gmail.com> wrote:
[...]
So, ECL starts up without problems now, but there is an (apparently) known issue with GC. The app crashes, seemingly during the first cycle of GC, see attached backtrace. But I noticed these lines in the 'ecl-android' project (github) of old, which has also an 'iOS' directory with an example app. There you find these lines before 'cl_boot': int argc = 1; char *argv[256]; argv[0] = "ecl"; GC_allow_register_threads(); GC_register_my_thread((const struct GC_stack_base *)argv); GC_stackbottom = (char*)(argv+255); // corrected to 'char*' (was: 'void*') setenv("ECLDIR", "", 1); cl_boot(argc, argv); Now, if I put the above lines before 'cl_boot', the app works. Does anybody know why this is needed, and what it is doing? Because if my Lisp app grows (I tried to include :cl-ppcre), then the app crashes again, despite the above hack (and with the same backtrace of the attachment). Of course I already tried bigger vector sizes (up to 8192) instead of 256, but that doesn't solve it. What else could I try? Thanks, Paul
On 9/25/19, PR <polos.ruetz@gmail.com> wrote:
Does anybody know why this is needed, and what it is doing? Because if my Lisp app grows (I tried to include :cl-ppcre), then the app crashes again, despite the above hack (and with the same backtrace of the attachment).
Answering myself both questions: for the GC issue, I found this thread from 2010: https://mailman.common-lisp.net/pipermail/ecl-devel/2010-July/007751.html The solution to the other problem (crash if initial Lisp library is big): well, the most obvious thing to do seems to just make a smaller initial library, and loading the other parts later on. If that still will cause me problems, I'll let you know. Paul
On 9/26/19, some <nobody> wrote: [...] ...and if you were wondering if this got somewhere, here a practical link: https://gitlab.com/eql/eql5-ios
participants (3)
-
Gunter Königsmann -
Marius Gerbershagen -
PR