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