Arch Linux User Repository

I have added openssl as dependency, also thanks Martchus.

Strange - anything interesting to find in the Android log? I don't think ldd works generally with Android binaries because it internally tries to invoke the standard dynamic linker. You can use readelf and objdump instead. E.g. use readelf -d to check whether the soname does not include a version number. Having a version number is a common problem preventing Android to load libraries.

If nothing helps, disable use of system libjpeg again. When I have time I can try to reproduce the issue myself.

I can trick the build system into including the libjpeg.so, libqjpeg.so into the APK (and also libplugins_imageformats_libqjpeg.so,to match how other image plugins appear into the APK), but it still won't load. I can't ldd the libqjpeg.so ("libq*.so not a dynamic executable") to see if the path to libjpeg is messed up, do I need an arm or android version?

Long story short, there is no jpeg support into QImage, which is not great. Building the same project on another OS works so I'm guessing having them accept that as a bug will be extra difficult (even if it is...)

@Emeric I believe the mechanism behind this "Skipping .... It has unmet dependencies ..." message is actually for excluding plugins when the corresponding Qt module isn't used anyways. That's presumably androiddeployqt's way to decide which plugins to bundle and which not. Maybe the recent change to use system libjpeg (rather than the version bundled with Qt) causes this issue. It is likely that upstream never tested using system libjpeg under Android (they not even allowed to find the library via pkg-config, see my patch: https://aur.archlinux.org/cgit/aur.git/tree/0004-Use-pkg-config-to-find-libjpeg.patch?h=android-aarch64-qt5).

You can possibly "trick" androiddeployqt by linking your app against libjpeg. Maybe it also works to add libjpeg explicitly to "android-extra-libs" (within the JSON file for androiddeployqt). Maybe it also works to add the plugin explicitly to "android-extra-plugins". Just play around with it...

But this sounds like an upstream bug (although it has likely very low prio for them). To file a bug it would be good to share your project or to come up with a minimal project to reproduce.

The jpeg plugin is not shipped in my apk with the 5.13 release, I'm not sure why but I do have this in my traces: -- Skipping /opt/android-libs/aarch64/plugins/imageformats/libqjpeg.so. It has unmet dependencies: lib/libjpeg.so. I can see the file aarch64/lib/libjpeg.so... Other image plugins are working. Also, could we maybe create a forum post (or anything) for all issues related to android and arch developement and packaging?

Well I hope they at least give the option to configure those paths instead of forcing us to do some some hackery to make the thing work :/

https://bugreports.qt.io/browse/QTBUG-68202

I hope this change will not interfere with our way of packaging Qt for Android. And I'm currently using androiddeployqt via CMake which hopefully continues to work like before as well. The change to the directory structure mentioned in the ticket description (libs folder will have an ABI subfolder libs/armeabi-v7a, libs/arm64-v8a,etc) sounds scary. I hope they didn't implement it that way in the end...

@hipersayan_x Ok, I'll try to fix the architectures when I have time. I can also try to user your environment packages. (The set-env.sh I'm using is taken from the OpenSSL documentation.) Maybe that also just fixes the problem.

@Martchus I have updated the package with your changes but since the openssl x86 packages does not compiles I did not added it as a dependency, if possible I want all architectures to have equal support.

@Martchus ok no problem, I will check it.