Qt 5.12 and Android arm64 build

With Qt 5.12 coming soon (end this month), I gave the beta #4 a try today.
My focus was on the cross build of Subsurface-mobile for Android. Obviously,
I ran in some problems, but nothing that seems mayor. One weird thing I
could not solve up to now is an undefined reference from the linker
(QtAndroid::runOnAndroidThread); a construct to set the color of the header
and footer to our liking.
With Qt 5.12 also a build for arm64 architecture becomes feasible. And I
succeeded in a running arm64 app on my device. Also here, relatively
straightforward (in hindsight). This requires a newer API that the currently
used 16. I used API 21 (corresponding to Android 5.0).
So, my question for Dirk: interested in set of patches for all this?
Obviously, no hurry here, as 5.12 is still beta. I between I might take a
look into clang instead of gcc for the mobile app, as Android had moved away
from gcc, and support will end someday.

Yes, I'd love patches. Please appropriately ifdefed for Qt 5.12 since we
still build against 5.11. And yes, I'd love to see someone figure out the
clang issues. Qt was one of the projects that still built their binaries
with gcc (and I was told that you can't mix and match). Will there be an
Android Qt 5.12 built with clang?

Thanks

/D

Thiago Macieira

2018-11-15 00:52:15 UTC

Will there be an Android Qt 5.12 built with clang?

I don't know if it will be pre-built as such, but Clang support is now present
in 5.12.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

Thiago Macieira

2018-11-15 00:51:24 UTC

Post by Jan Mulder
With Qt 5.12 coming soon (end this month), I gave the beta #4 a try
today. My focus was on the cross build of Subsurface-mobile for Android.
Obviously, I ran in some problems, but nothing that seems mayor. One
weird thing I could not solve up to now is an undefined reference from
the linker (QtAndroid::runOnAndroidThread); a construct to set the color
of the header and footer to our liking.

That sounds like a mix of two Qt versions, since runOnAndroidThread is defined
in qjnihelpers.cpp, inside QtCore, without any #if. That is, you're compiling
against 5.12, but linking (or running) against 5.11. Check your environment.

Post by Jan Mulder
With Qt 5.12 also a build for arm64 architecture becomes feasible. And I
succeeded in a running arm64 app on my device. Also here, relatively
straightforward (in hindsight). This requires a newer API that the
currently used 16. I used API 21 (corresponding to Android 5.0).

Note that this will make use of Clang to build, instead of GCC of the older
SDKs. Clang produces much larger binaries, even at extreme size optimisation
(-Oz).

Post by Jan Mulder
So, my question for Dirk: interested in set of patches for all this?
Obviously, no hurry here, as 5.12 is still beta. I between I might take
a look into clang instead of gcc for the mobile app, as Android had
moved away from gcc, and support will end someday.

The first -rc is expected next week and these days it means any RC could be
the final release one week later, if nothing major is found. If you have
issues, please report them so we decide whether the RC is good or not.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

Jan Mulder

2018-11-15 09:38:36 UTC

One weird thing I could not solve up to now is an undefined reference from
the linker (QtAndroid::runOnAndroidThread); a construct to set the color
of the header and footer to our liking.

Did check, and do not find any reference to 5.11 in the build logs, have
no Qt related environment variables, moved my 5.11 tree away and did a
full rebuild, and the mobile app is telling in the log: build with
5.12.0, runtime from 5.12.0. So, while I would like to believe that
there is something wrong in my environment, I have hard time pinpointing it.

This said, I just found something that seems related. Interfacing using
Bluetooth using the mobile app crashes. Logcat shows: AndroidRuntime:
java.lang.UnsatisfiedLinkError: No implementation found for void
org.qtproject.qt5.android.bluetooth.QtBluetoot
hBroadcastReceiver.jniOnReceive. So also here, a link time error.
Obviously, the big question is here: is this an error in the Subsurface
build process, or is there something missing in Qt 5.12 (as I believe I
use 5.12, and do not mix up versions). I can not be missing QtCore as
the app would not run in any way.

With Qt 5.12 also a build for arm64 architecture becomes feasible. And I
succeeded in a running arm64 app on my device. Also here, relatively
straightforward (in hindsight). This requires a newer API that the
currently used 16. I used API 21 (corresponding to Android 5.0).

Note that this will make use of Clang to build, instead of GCC of the older
SDKs. Clang produces much larger binaries, even at extreme size optimisation
(-Oz).

This might be true for qmake builds, but I'm sure I build using gcc
while using API 21 in our cmake style build. I think that up to the
latest versions of the API, gcc is still possible, but it will be
removed at some point.

So, my question for Dirk: interested in set of patches for all this?
Obviously, no hurry here, as 5.12 is still beta. I between I might take
a look into clang instead of gcc for the mobile app, as Android had
moved away from gcc, and support will end someday.

I will definitely file a Qt bug when I'm convinced it is not an issue at
the Subsurface side. But this will require a small demonstrator, and not
a full blown build of Subsurface-mobile.

--jan

Jan Mulder

2018-11-15 20:58:42 UTC

Post by Jan Mulder

One weird thing I could not solve up to now is an undefined reference from
the linker (QtAndroid::runOnAndroidThread); a construct to set the color
of the header and footer to our liking.

Did check, and do not find any reference to 5.11 in the build logs, have
no Qt related environment variables, moved my 5.11 tree away and did a
full rebuild, and the mobile app is telling in the log: build with
5.12.0, runtime from 5.12.0. So, while I would like to believe that
there is something wrong in my environment, I have hard time pinpointing it.
This said, I just found something that seems related. Interfacing using
java.lang.UnsatisfiedLinkError: No implementation found for void
org.qtproject.qt5.android.bluetooth.QtBluetoot
hBroadcastReceiver.jniOnReceive. So also here, a link time error.
Obviously, the big question is here: is this an error in the Subsurface
build process, or is there something missing in Qt 5.12 (as I believe I
use 5.12, and do not mix up versions). I can not be missing QtCore as
the app would not run in any way.

Let me answer my own question. I made a small android app from one of
the Qt examples. Embedded the runOnAndroidThread() call, and that
compiles and runs as expected. Ok, a fully different build environment
(qmake, clang) but it just works. So its a problem in our build process
and not an Qt issue.

--jan

Jan Mulder

2018-11-23 14:34:46 UTC

Post by Jan Mulder

One weird thing I could not solve up to now is an undefined
reference from
the linker (QtAndroid::runOnAndroidThread); a construct to set the color
of the header and footer to our liking.

Did check, and do not find any reference to 5.11 in the build logs,
have no Qt related environment variables, moved my 5.11 tree away and
did a full rebuild, and the mobile app is telling in the log: build
with 5.12.0, runtime from 5.12.0. So, while I would like to believe
that there is something wrong in my environment, I have hard time
pinpointing it.
This said, I just found something that seems related. Interfacing
AndroidRuntime: java.lang.UnsatisfiedLinkError: No implementation
found for void org.qtproject.qt5.android.bluetooth.QtBluetoot
hBroadcastReceiver.jniOnReceive. So also here, a link time error.
Obviously, the big question is here: is this an error in the
Subsurface build process, or is there something missing in Qt 5.12 (as
I believe I use 5.12, and do not mix up versions). I can not be
missing QtCore as the app would not run in any way.

A status update. After hours of rebuilding, NDK version changes etc. I
managed to build Subsurface-Mobile for Android using the following
components: OpenJDK 10, Android NDK 18b, latest Android SDK, Qt 5.12
Beta 4, clang using LLVM libc++, both for arm and arm64 architectures.

This build does not have the problem mentioned above (runOnAndroidThread
undefined on link time), so the borders are working again. So,
definitely, my first attempt described above was broken (highly likely
related to mixup of GNU stl and libc++ headers).

Unfortunately, the runtime crash on device is still there, shown in the
logcat as as follows:

11-23 13:09:16.180 10906 10906 E AndroidRuntime:
java.lang.UnsatisfiedLinkError: No implementation found for void org.qtpr
oject.qt5.android.bluetooth.QtBluetoothBroadcastReceiver.jniOnReceive(long,
android.content.Context, android.content.Inten
t) (tried
Java_org_qtproject_qt5_android_bluetooth_QtBluetoothBroadcastReceiver_jniOnReceive
and Java_org_qtproject_qt5_an
droid_bluetooth_QtBluetoothBroadcastReceiver_jniOnReceive__JLandroid_content_Context_2Landroid_content_Intent_2)
11-23 13:09:16.180 10906 10906 E AndroidRuntime: at
org.qtproject.qt5.android.bluetooth.QtBluetoothBroadcastReceive
r.jniOnReceive(Native Method)

This crash can be triggered at will, by simply switching BT on/off, and
unfortunately, that missing code is also triggered on a regular BT/BLE
download, making the app more or less useless for any BT/BLE use at this
point.

I did review numerous recent Qt changes in the related qtconnectivity
and qtbluetooth on source code level (not building Qt from source, only
code reading). Nothing I found sticks out as suspicious, and nothing to
really substantiate a Qt bug. So, basically I'm on a dead end at this
point, and I can better go cave diving the coming days :-)

--jan

Dirk Hohndel

2018-11-23 18:27:03 UTC

Wow.

This build does not have the problem mentioned above (runOnAndroidThread undefined on link time), so the borders are working again. So, definitely, my first attempt described above was broken (highly likely related to mixup of GNU stl and libc++ headers).

Orgs.

11-23 13:09:16.180 10906 10906 E AndroidRuntime: java.lang.UnsatisfiedLinkError: No implementation found for void org.qtpr
oject.qt5.android.bluetooth.QtBluetoothBroadcastReceiver.jniOnReceive(long, android.content.Context, android.content.Inten
t) (tried Java_org_qtproject_qt5_android_bluetooth_QtBluetoothBroadcastReceiver_jniOnReceive and Java_org_qtproject_qt5_an
droid_bluetooth_QtBluetoothBroadcastReceiver_jniOnReceive__JLandroid_content_Context_2Landroid_content_Intent_2)
11-23 13:09:16.180 10906 10906 E AndroidRuntime: at org.qtproject.qt5.android.bluetooth.QtBluetoothBroadcastReceive
r.jniOnReceive(Native Method)
This crash can be triggered at will, by simply switching BT on/off, and unfortunately, that missing code is also triggered on a regular BT/BLE download, making the app more or less useless for any BT/BLE use at this point.

Not good. From the looks of it this does sound like it might be a Qt issue, so I'm adding Alex...

I did review numerous recent Qt changes in the related qtconnectivity and qtbluetooth on source code level (not building Qt from source, only code reading). Nothing I found sticks out as suspicious, and nothing to really substantiate a Qt bug. So, basically I'm on a dead end at this point, and I can better go cave diving the coming days :-)

Be save diving.
Do you have pointers on how to re-create your build? Any patches needed? Specific versions?

Thanks

/D

Jan Mulder

2018-11-24 08:23:36 UTC

Wow.

Orgs.

Not good. From the looks of it this does sound like it might be a Qt issue, so I'm adding Alex...

Something I overlooked. I was testing all the time with builds for arm64
architecture, and there I can reproduce this non-implemented
jniOnReceive issue at will. However, testing for arm, all just works.
That's definitely a clue, and I can definitely not rule out an issue in
my build stack. The good news is that we can build a working arm version.

Be save diving.
Do you have pointers on how to re-create your build? Any patches needed? Specific versions?

Will push things to my github asap, but first need to do some cleanup.
Notice that Qt 5.12 is not yet downloadable (as not yet released), and
all my work is currently local build only. No Travis integration yet.

--jan

Dirk Hohndel

2018-11-24 20:22:35 UTC

This crash can be triggered at will, by simply switching BT on/off, and unfortunately, that missing code is also triggered on a regular BT/BLE download, making the app more or less useless for any BT/BLE use at this point.

Not good. From the looks of it this does sound like it might be a Qt issue, so I'm adding Alex...

Something I overlooked. I was testing all the time with builds for arm64 architecture, and there I can reproduce this non-implemented jniOnReceive issue at will. However, testing for arm, all just works. That's definitely a clue, and I can definitely not rule out an issue in my build stack. The good news is that we can build a working arm version.

With Qt 5.12 scheduled for release in less than two weeks (they are now aiming for December 5th, it seems), getting a handle on whether that's an issue in your build stack or with Qt might be very interesting to Alex :-)