ECL cross-compiled for 'aarch64' considered stable?

[PR]

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