July 2017 - ecl-devel - mailman3.common-lisp.net

EQL5-Android (port of EQL5 to the Android platform): a first example
by PR 04 Jul '17

04 Jul '17

For those interested in tablet / mobile development: I finally got a first example of EQL5 to work on Android, see 'tic-tac-toe' example, of course using both QML and Lisp! https://gitlab.com/eql/EQL5-Android Paul

2 2

Re: Android question: does cross-compiling require a 32 bit host ECL?
by Daniel Kochmański 04 Jul '17

04 Jul '17

Ah, there is one more problem with CC. If ECL versions differ (for instance 16.1.2 and 16.1.3), the resulting code will compile, but it won't work. The reason for that lies in fact, that symbols are indexed by positions in the table, and they may differ between versions. That said, if the index is different for the same version but with different features compiled in (i.e unicode and unicode) - all should work fine. If it doesn't, it is a bug. On 04.07.2017 07:31, Daniel Kochmański wrote: > > On 03.07.2017 21:17, Andy Hefner wrote: >> Interesting. Sometime in the past I recall reading that this was by >> design, and the compiler was intended to produce portable C. I'm >> curious to what extent this used to be true, or if the departure from >> this philosophy was deliberate. >> > Well, it depends on what you consider portable C. ECL compiler tries > to get the most from the used C compiler - before build it uses > autotools to detect features it can use. > > Lately we have made C99-compliant C compiler a requirement, so types > like uint64_t should be guaranteed to exist. That said ECL still work > with compilers older than that. The problem is, that if ECL detect > long double and its companianions (sinl, cosl), it produces code using > them, so we long-float type in CL is more accurate. If we > cross-compile with compiler not having sinl/cosl (not c99 conformant, > like in Android), we are busted. Workaround for that is to build host > ECL without long double. Correct solution is to have *target-features* > and long-float feature verified at runtime (not runtime) - something tbd. > > Requirement to set ABI=32 deliberely is for some obscure reason in > GMP. It is a bug to be fixed if possible. > > Interesting fact is that ECL has internal notion of the target > machine, but there is not mechanism currently to select one. When I > understand the compiler well enough I plan to make it configurable at > runtime - right now though cross compilation is rather a mundane task. > > NB: some other types may be used with ECL (namely - sse packs). > > To sum up: ECL produces portable C code, but: > 1) there may be some backward compatibility constraints (long double), > 2) there are some bugs wrt ABI compatibility if cross-compiled against > different libecl.so (caused by gmp), > 3) cross compilation needs more love (easily switching compiler and > flags etc), > 4) most of the architecture for 3) is implemented, it's a matter of > groking it and fixing some issues. > > I hope that answers your questions. > > Best regards, > Daniel

1 0

Android question: does cross-compiling require a 32 bit host ECL?
by PR 01 Jul '17

01 Jul '17

Hi again, In the process of porting EQL5 to Android, I stumbled upon this problem: The app crashes on Android during read_VV(), if the lisp library has been cross-compiled using a 64 bit ECL. To solve this problem, I need to use a 32 bit ECL for cross-compiling: but this would mean that for cross-compiling EQL5 apps we are required to stay with 32 bit ECL for EQL5. Probably not a big deal, but could the Android gurus confirm this? Thanks, Paul

2 2

FEprogram_error vs FEprogram_error_noreturn
by Kris Katterjohn 01 Jul '17

01 Jul '17

Hey, I notice that there is a FEprogram_error and a FEprogram_error_noreturn in src/c/error.d; however, it looks like these functions are identical aside from their names. I copied these to different files and diff'd them: --- test 2017-06-28 15:39:32.199877688 -0500 +++ test2 2017-06-28 15:39:32.199877688 -0500 @@ -1,5 +1,5 @@ void -FEprogram_error(const char *s, int narg, ...) +FEprogram_error_noreturn(const char *s, int narg, ...) { cl_object real_args, text; ecl_va_list args; FEprogram_error_noreturn was added in commit 7d9fb8bb. I think it was added because FEprogram_error didn't have the noreturn attribute, so FEprogram_error_noreturn was introduced with this attribute. However, it looks like FEprogram_error (and others) got this attribute in commit 790d466c. (This all happened in Feb 2010.) Currently in src/h/external.h: extern ECL_API void FEprogram_error(const char *s, int narg, ...) ecl_attr_noreturn; extern ECL_API void FEprogram_error_noreturn(const char *s, int narg, ...) ecl_attr_noreturn; They are both used throughout src/c. It seems like one of these should be removed. If so, I can remove one of them and change all of the calls to it. I would say keep FEprogram_error and remove FEprogram_error_noreturn. If these changes are desired, then I can open up a new Merge Request with these changes after my currently open Merge Request is done (to avoid conflicts). Cheers, Kris Katterjohn

3 3