Package Details: android-aarch64-qt5 5.13.2-1

Git Clone URL: (read-only, click to copy)
Package Base: android-aarch64-qt5
Description: Qt 5 for Android
Upstream URL:
Licenses: GPL3, LGPL
Groups: android-qt5
Submitter: hipersayan_x
Maintainer: hipersayan_x
Last Packager: hipersayan_x
Votes: 11
Popularity: 0.49
First Submitted: 2018-11-22 19:14
Last Updated: 2019-11-16 17:56

Dependencies (24)

Required by (1)

Sources (5)

Latest Comments

1 2 3 4 5 Next › Last »

hipersayan_x commented on 2019-12-14 21:44

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.

Martchus commented on 2019-12-14 16:33

There's actually also another block for Android. The following patch brings me already further:

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/] 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.

Martchus commented on 2019-12-14 15:35

I've just tried Qt 5.14.0 and ran into the following error:
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 \
    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):

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

Emeric commented on 2019-10-24 10:38

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.

hipersayan_x commented on 2019-10-08 21:52

I have added openssl as dependency, also thanks Martchus.

Martchus commented on 2019-10-05 11:00

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.

Emeric commented on 2019-10-05 09:44

I can trick the build system into including the, into the APK (and also,to match how other image plugins appear into the APK), but it still won't load. I can't ldd the ("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...)

Martchus commented on 2019-10-04 20:27

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

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.

Emeric commented on 2019-10-04 14:34

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/ It has unmet dependencies: lib/ I can see the file aarch64/lib/ 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?

hipersayan_x commented on 2019-09-27 02:20

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