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

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

Android question (for porting EQL5 to that platform)
by PR 27 Jun '17

27 Jun '17

Hi all, I'm currently trying to port EQL5 to the android platform. There is a big show-stopper to this: - building ECL for android only works with NDK r9 (which is really old already) - building EQL5 for android only works with NDK r15 (for Qt 5.9; but Qt5 requires a recent NDK anyway) Since I need to link the both together, I have an incompatibility issue during the final linker step. Now, the only solution I see (so far) would be this: making ECL work with latest NDK r15. Did anybody already give it a try? Is it feasible at all? (We need to look at what we would be gaining: EQL5 on android, using QML and Lisp, just would be too nice to have!!) Thanks, Paul

2 5

ECL 16.1.3 on mingw-w64 64-bit
by Dave Richards 23 Jun '17

23 Jun '17

I am able to build ECL on mingw-w64 in 32-bit mode, but when I build in 64-bit mode it fails with a Lisp Initialization error. I notice that when building under MSVC there is an ECL_WIN64 make variable that must be set. Is there a similar variable for mingw-w64? If so, I have not found it. Thanks! Dave

2 1

Running examples from REPL
by Ivan Truskov 04 Jun '17

04 Jun '17

Hello I am trying to have a go with ECL. I have built ECL on windows 10 machine with 64-bit Visual Studio (community version) and i am trying to run example on build that comes with the source code. In open window of ecl.exe, i go to the folder, and call load on "readme.lisp". Then, on the first lines of it, i recieve the following error and the execution stops. Error as follows: > Condition of type: SIMPLE-ERROR > In COMPILE-FILE-PATHNAME, the type OBJECT is unsupported. > Available restarts: > > 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. > > Broken at SI:BYTECODES. [Evaluation of: (C::COMPILER-CC "hello_aux.c" > (COMPILE-FILE-PATHNAME "hello_aux.c" :TYPE :OBJECT))] In: #<process > TOP-LEVEL>. > File: > #P"C:/Users/Kurvivor/Development/ecl-16.1.3/examples/build/readme.lisp" > (Position #1054) How can i get past this error? Related question: how do i set up the compiler used and compiler environment? How do i check it (determine what current setings are)? Thanks in advance!

2 1

Recipe for wrapping C++ files
by Иван Трусков 25 May '17

25 May '17

Hello How can one bridge between C++ objects and CL? For example, given a class to the lines of class A { public: A(int q, int w); ~A(); void foo(int q); int bar(); }; that has its instances wrapped in smart pointers, how can that functionality be made available from embedded Common Lisp? Sorry if that's too general of a question. I am somewhat ignorant at the moment, and would appreciate any tips as to where to dig to solve that

2 3

random failure on run-program on develop branch
by Fabrizio Fabbri 23 May '17

23 May '17

Hi all,I'm sitting on the very latest develop branch on OSX. I'm noticed that some time the compilation will hang when the compiler is invoked. I'm not able to reproduce it consistently and if I kill the build and retry it does complete. Empirical observation show that it is happen when we invoke the compiler to compile the generated code. However also ansi-test have the same problem and so far I'm not be able to complete an ansi-test run, so with ansi-test is reproducible semi consistently I have a previous version and on the same machine it does work fine so I'll probably start a git bisect but It does take time as I have to do a full build and a ansi-test run. I was also wondering if that it's my environment or someone have the same issue. Given the pattern of the problem I feel like we are leaking file descriptor, but I may be wrong. cheersf.

1 1

quick way to test compatibility
by Gross, Daniel 08 Apr '17

08 Apr '17

Hi, I have some lisp source code and would like to test compatibility with ECL. Is there a simple way to test for compatibility. Ideally, I would compile and/or repl and run the code with ecl. thank you, Daniel --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

4 4

[CfPart] 10th European Lisp Symposium, Apr 3-4 2017, Brussels
by Didier Verna 03 Mar '17

03 Mar '17

ELS'17 - 10th European Lisp Symposium VUB - Vrije Universiteit Brussel Belgium April 3-4, 2017 In co-location with <Programming> 2017 Sponsors: Brunner Software GmbH, Franz Inc., LispWorks Ltd. and EPITA http://www.european-lisp-symposium.org/ Recent news: - Invited speakers announced (see below) - Registration open. Don't miss the March 13 deadline for the full <Programming> conference early bird discount! The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. Keynote speakers: - Hans Hübner -- Identity in a World of Values - Bohdan B. Khomtchouk -- How the Strengths of Lisp Facilitate Building Complex and Flexible Bioinformatics Applications Important dates: - 13 Mar 2017 Early registration deadline - 03-04 Apr 2017 Symposium - 05-06 Apr 2017 <Programming> main tack Programme chair: Alberto Riva, University of Florida, USA Programme committee: Marco Antoniotti, Università Milano Bicocca, Italy Marc Battyani, FractalConcept Theo D'Hondt, Vrije Universiteit Brussel, Belgium Marc Feeley, Université de Montreal, Canada Erick Gallesio, Université de Nice Sophia-Antipolis, France Stelian Ionescu, Google Rainer Joswig, Independent Consultant, Germany António Menezes Leitão, Technical University of Lisbon, Portugal Nick Levine, RavenPack Henry Lieberman, MIT, USA Mark Tarver, Shen Programming Group Jay McCarthy, University of Massachusetts Lowell, USA Christian Queinnec, Université Pierre et Marie Curie, France François-René Rideau, Bridgewater Associates, USA Nikodemus Siivola, ZenRobotics Ltd Alessio Stalla, Università degli Studi di Genova, Italy Chris Stacy, CS Consulting Search Keywords: #els2017, ELS 2017, ELS '17, European Lisp Symposium 2017, European Lisp Symposium '17, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2017, European Lisp Conference '17 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0