Package Details: android-aarch64-qt5 5.15.2-2

Git Clone URL: https://aur.archlinux.org/android-aarch64-qt5.git (read-only, click to copy)
Package Base: android-aarch64-qt5
Description: Qt 5 for Android
Upstream URL: https://www.qt.io
Licenses: GPL3, LGPL
Groups: android-qt5
Submitter: hipersayan_x
Maintainer: None
Last Packager: hipersayan_x
Votes: 14
Popularity: 0.000000
First Submitted: 2018-11-22 19:14 (UTC)
Last Updated: 2021-03-14 20:01 (UTC)

Dependencies (26)

Sources (4)

Pinned Comments

hipersayan_x commented on 2021-07-07 15:05 (UTC) (edited on 2021-07-07 15:09 (UTC) by hipersayan_x)

I'll drop this package, I been thinking and there are a lot of strong reasons not to waste any time maintaining it.
KDE doesn't provide an easy way to download the entire Qt source code in a single package, like in the official Qt releases.
Also, KDE doesn't provides tagged versions, I've to keep tracking manually the latest commits, or converting it to a git package.
It will require to split this package into 47x4 packages, 47 Qt modules and 4 architectures to maintain, that's 188 packages to maintain, absurd!
Cloning a git repository is slower than just downloading a source package file, making the build even much slower and painful.
Is a lot of work for something that will be dead in 1 year or 2 at most.
Good luck to the one that will step up to take care of this monstrosity, to the rest of developers, don't be lazy and consider switching to Qt6.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

Emeric commented on 2019-10-05 09:44 (UTC)

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...)

Martchus commented on 2019-10-04 20:27 (UTC) (edited on 2019-10-04 20:29 (UTC) by Martchus)

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

Emeric commented on 2019-10-04 14:34 (UTC)

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?

hipersayan_x commented on 2019-09-27 02:20 (UTC)

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

Martchus commented on 2019-09-26 15:10 (UTC)

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

Martchus commented on 2019-09-11 08:24 (UTC)

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

hipersayan_x commented on 2019-09-10 23:48 (UTC)

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

hipersayan_x commented on 2019-09-09 23:26 (UTC)

@Martchus ok no problem, I will check it.

Martchus commented on 2019-09-09 20:53 (UTC)

@hipersayan_x I added the packages to the AUR but haven't tested them yet.

hipersayan_x commented on 2019-09-09 15:44 (UTC)

@Martchus Will check thanks. Also, can you upload the x86 and x86-64 packages for openssl?

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »