ecl: add package for embeddable common lisp #6080
Conversation
| @@ -1,8 +1,7 @@ | |||
| TERMUX_PKG_HOMEPAGE=https://common-lisp.net/project/ecl/ | |||
| TERMUX_PKG_DESCRIPTION="ECL (Embeddable Common Lisp) is an interpreter of the Common Lisp language." | |||
| TERMUX_PKG_LICENSE="LGPL-2.0" | |||
There was a problem hiding this comment.
fwiw ecl is licensed under lgpl-2.1+, not lgpl-2.0
There was a problem hiding this comment.
I put LGPL-2.0 here because it says "Version 2" in https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop/COPYING
There was a problem hiding this comment.
you are right, the included license is outdated (we already
bundle lgpl-2.1+ sources of other libraries)
(I will also need to change that), either way, since there is
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.
it should be at least mentioned as lgpl-2.0+
| @@ -0,0 +1,46 @@ | |||
| TERMUX_PKG_HOMEPAGE=https://common-lisp.net/project/ecl/ | |||
| TERMUX_PKG_DESCRIPTION="ECL (Embeddable Common Lisp) is an interpreter of the Common Lisp language." | |||
There was a problem hiding this comment.
ecl is a compiler with runtime, not an interpreter
There was a problem hiding this comment.
Hey @dkochmanski, good to see you here :). I just copied the first sentence from https://common-lisp.net/project/ecl/main.html. Happy to adjust it if you think it's not correct.
There was a problem hiding this comment.
thanks, I need probably to rephrase it. If you are interested in details:
ecl always compiles the code (either with the bytecodes compiler or the c compiler), in the former case it executes the bytecode in a bytecode vm and that could be called interpreter.
There was a problem hiding this comment.
I guess it can be called an interpreter because python and most other scripting languages work the same way: compile to bytecode, then run that. ECL has the additional option of compiling to C.
There was a problem hiding this comment.
I disagree, interpretation has a well defined meaning and it does not fit the model of compile->bytecode->execute. But I don't care enough to insist (especially that our own webpage is wrong :-)
|
@dkochmanski BTW, since you are reading this, it would be nice to have android cross_config definitions for 686 and x86_64 in the ECL repo. That would enable building ECL for all termux architectures. |
|
I'd rather fix the compiler altogether so it is possible to have a host with a different set of features (i.e so it is possible to cross-cc arm64 on x86) // edit: but I don't know when it will happen, so if you submit a merge request with such definitions it will be probably merged |
But this is what we're doing here, and it works! The package build runs on x86_64 and compiles ECL for aarch64 and arm (32bit). The cross_config is just the output of some of the autoconf checks, right? Not sure how to generate these values, does it output such a file during ./configure ? Also, I don't have an x86_64 android device and therefore can't check what the values should be, though it might be possible to guess them from a normal linux/x86_64 build. |
|
I'm saying that it is impossible to cross-compile with host ECL 32-bit to target ECL 64-bit (and vice versa), for instance from x86 (not x86-64) to aarch64. I'm surprised that it works for x86-64 to arm32, but I don't remember the exact details of the issue. cross_config also specifies some of the target machine features (i.e stack direction, size of various types, the file_cnt implementation of the target compiler etc). so yes, after a thought, cross configs for various targets would be still useful even after we fix the issue with not matching host/target number of bits. |
Hmm, so does this mean the arm (32bit) termux build of ECL is broken by definition? Because we are compiling that on 64bit. Can you verify? I don't have a 32bit arm phone, maybe you have one. Just install it with apt and check if it runs. If it's currently impossible to compile 32bit ECL on a 64bit host, we might need to fix this package to build a 32bit host ECL when compiling for 32bit target. |
|
You may build for arm32 on x86-64 host, but you must build the host ecl with 32 bit, i.e no, I don't have 32bit phone. but if there were a problem, the compiler would complain and it would not build -- if it successfully produced a binary then it should be fine. |
|
Yeah, I saw this in the INSTALL file, but didn't add it because the termux build infrastructure only does the host build once and then caches it. So testing this would be annoying because I'd need to find a way to reset the host build when compiling for arm32. Another potential issue is that the build environment container might not have a 32bit host libc and toolchain available (didn't try it). If you say it should work if it compiles OK we can just leave it as is for now. I'll investigate it when I have another free night, but please note I'm just a random Termux user and CL enthusiast, might not get to it soon. You guys might also be able to fix it upstream in the meantime. |
|
Right. thank you for adding ecl to termux, I'm sure that this will benefit many people. |
Fixes #183
I've tried this for aarch64 and the resulting binary works.