On 15-11-2018 21:58, Jan Mulder wrote:
On 15-11-2018 10:38, Jan Mulder wrote:
On 15-11-2018 01:51, Thiago Macieira wrote:
On Wednesday, 14 November 2018 13:28:04 PST Jan Mulder wrote:
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.
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.
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.
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
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
