ok, many thanks (me seems you're a very good ECL maintainer!)
2017-07-01 22:20 GMT+02:00, Daniel Kochmański :
> Yes, this is true. The problem is that ECL compiler doesn't have
> distinction between host architecture and target architecture (it just
> transpiles code) - so if host implementation h
Yes, this is true. The problem is that ECL compiler doesn't have
distinction between host architecture and target architecture (it just
transpiles code) - so if host implementation has long-double, it will
produce C code using long-double, if 64 bit integers are present, then
transpiled code is
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
They are exported for sake of the transpiled CL code. We could provide
such define though, for instance in legacy.h header, if there might be
code using it. I would keep it removed though unless somebody complains,
then we will add it back in form of define.
On 01.07.2017 00:11, Fabrizio Fabb
Il giorno 29 giu 2017, alle ore 10:25, Daniel Kochmański
ha scritto:
>> 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 they do the same then ye
