Arch Linux User Repository

Those libraries seems to be defined in libwebpdecoder.a or libwebp.a, maybe adding the libraries to the .pro file will solve the problem? anyway I will check next week.

There's actually also another block for Android. The following patch brings me already further: https://github.com/Martchus/qtbase/commit/576c1681f59dbb473f4a3d394bf57997cf817378

Now it fails with:

.obj/aarch64/alpha_processing.o: In function `WebPInitAlphaProcessing':
alpha_processing.c:(.text+0x3e8): undefined reference to `WebPInitAlphaProcessingNEON'
.obj/aarch64/dec.o: In function `VP8DspInit':
dec.c:(.text+0xac): undefined reference to `VP8DspInitNEON'
.obj/aarch64/enc.o: In function `VP8EncDspInit':
enc.c:(.text+0x28c): undefined reference to `VP8EncDspInitNEON'
.obj/aarch64/filters.o: In function `VP8FiltersInit':
filters.c:(.text+0x4c): undefined reference to `VP8FiltersInitNEON'
.obj/aarch64/lossless.o: In function `VP8LDspInit':
lossless.c:(.text+0x1090): undefined reference to `VP8LDspInitNEON'
.obj/aarch64/lossless_enc.o: In function `VP8LEncDspInit':
lossless_enc.c:(.text+0xc10): undefined reference to `VP8LEncDspInitNEON'
.obj/aarch64/rescaler.o: In function `WebPRescalerDspInit':
rescaler.c:(.text+0xd58): undefined reference to `WebPRescalerDspInitNEON'
.obj/aarch64/upsampling.o: In function `WebPInitUpsamplers':
upsampling.c:(.text+0x64): undefined reference to `WebPInitUpsamplersNEON'
.obj/aarch64/yuv.o: In function `WebPInitConvertARGBToYUV':
yuv.c:(.text+0x5fc): undefined reference to `WebPInitConvertARGBToYUVNEON'
yuv.c:(.text+0x600): undefined reference to `WebPInitSharpYUVNEON'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make[5]: *** [Makefile:398: ../../../../plugins/imageformats/libplugins_imageformats_qwebp_arm64-v8a.so] Error 1
make[5]: Leaving directory '/build/android-aarch64-qt5/src/qt-everywhere-src-5.14.0/qtimageformats/src/plugins/imageformats/webp'

That just seems to be another place where neon specific source files are not added to the build correctly. I'll try to update my patch tomorrow. If you have any ideas/suggestions let me know.

I've just tried Qt 5.14.0 and ran into the following error: https://paste.opensuse.org/14116450
The file which would provide the symbols the linker can't find is explicitly not added when compiling for Android:

!android {
    SSE2_SOURCES += painting/qdrawhelper_sse2.cpp
    SSSE3_SOURCES += painting/qdrawhelper_ssse3.cpp
    SSE4_1_SOURCES += painting/qdrawhelper_sse4.cpp \
                      painting/qimagescale_sse4.cpp
    ARCH_HASWELL_SOURCES += painting/qdrawhelper_avx2.cpp

    NEON_SOURCES += painting/qdrawhelper_neon.cpp painting/qimagescale_neon.cpp
    NEON_HEADERS += painting/qdrawhelper_neon_p.h
}

So something seems to be broken/inconsistent in their configure system now. I'm playing around with it a little bit, maybe I can find a workaround.

By the way, so far I restricted my builds to one arch at a time (and I only tried aarch64 so far): https://github.com/Martchus/PKGBUILDs/blob/update/mingw-w64-qt5/qt5/android-aarch64/PKGBUILD#L126

This Git branch also contains rebased patches (seems like 0001-Fix-clang-libc-build-under-Android.patch can be dropped).

Martchus, I didn't find anything weird in the logs no. Rebuilding Qt with the internal libjpeg works for me though, so I'm gonna stick with that.

hipersayan_x, openssl as dependency make the Qt Location maps works too, thanks.

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 :/