Hi,

I have a question about 'aarch64' cross compiling: Using a recent ECL git snapshot (2019-03-06) I could successfully cross-compile ECL to aarch64 (applying a small patch, more on this later), using android NDK 18b (which uses llvm).

Did anybody here run ECL on aarch64, and is it considered to be stable?

I'm asking because of my EQL5-Android project: I successfully compiled the REPL example to aarch64, but I encountered a severe memory corruption at startup. I found a (stupid) workaround for this, and it definitely happens only with the combination of Qt 5.12.1 and ECL on android. (Qt 5.12.1 on aarch64 runs stable without ECL). Once the android REPL example is started up, the app seems to run fine.

(The stupid workaround hack I use is calling the QApplication constructor twice, first on the stack, then on the heap; the used one is the one on the heap; without this the app would crash every time I call QCoreApplication::arguments(), which accesses 'argc' and 'argv' passed to 'main()': this means that the argc, argv data gets overwritten somehow on startup.)

Regarding the above mentioned patch to cross-compile to aarch64: I needed to comment out one line in 'build/ecl/config-internal.h':

//# define FILE_CNT(fp) ((fp)->_r)

Here the patch:

diff --git a/config-internal.h.orig b/config-internal.h index 2c0cd4c..a399192 100644 --- a/config-internal.h.orig +++ b/config-internal.h @@ -211,7 +211,7 @@ # define FILE_CNT(fp) ((fp)->_IO_read_end - (fp)->_IO_read_ptr) #endif #if 2 == 2 -# define FILE_CNT(fp) ((fp)->_r) +//# define FILE_CNT(fp) ((fp)->_r) // not available for 'aarch64' with recent android NDK #endif #if 2 == 3 # define FILE_CNT(fp) ((fp)->_cnt)

This is because the 'struct __sFILE' in latest NDKs is only opaquely defined, and they say that we can't rely on its internals. In fact, the definition in "struct_file.h" is this (android NDK 18b, which is llvm only, gcc just links to clang):

struct __sFILE { #if defined(__LP64__) char __private[152]; #else char __private[84]; #endif } __attribute__((aligned(sizeof(void*))));

You see, no internals revealed!

Any comments on this appreciated,

Paul