Package Details: android-armv7a-eabi-qt5 5.15.1-1

Git Clone URL: https://aur.archlinux.org/android-armv7a-eabi-qt5.git (read-only, click to copy)
Package Base: android-armv7a-eabi-qt5
Description: Qt 5 for Android
Upstream URL: https://www.qt.io
Licenses: GPL3, LGPL
Groups: android-qt5
Submitter: hipersayan_x
Maintainer: hipersayan_x
Last Packager: hipersayan_x
Votes: 19
Popularity: 0.000925
First Submitted: 2018-11-22 19:15
Last Updated: 2020-09-24 17:08

Dependencies (26)

Sources (4)

Latest Comments

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

Martchus commented on 2020-01-08 09:44

Just for the record, likely that's where you've got it: https://bugreports.qt.io/browse/QTBUG-80756

Martchus commented on 2020-01-07 19:14

Thanks, I'll try that when there's a patch for the CMake issue. And I'm afraid that's not the only problem with 5.14: https://lists.qt-project.org/pipermail/interest/2020-January/034372.html

hipersayan_x commented on 2020-01-07 18:26

Because you forgot to add

export ANDROID_TARGET_ARCH="${ANDROID_ABI}"

in your PKGBUILD. I had the same problem, I don't remember where I get the solution but it worked :-P

Martchus commented on 2020-01-07 16:04

I'm wondering why you don't need the sed command I've mentioned in this ticket: https://bugreports.qt.io/browse/QTBUG-80938

For me it otherwise tries to configure this for aarch64 (which obviously breaks when linking against armv7a-eabi libs). And when reading that the build system is actually supposed to run the configuration only for one hardcoded architecture I've just though WTF, seriously?

Martchus commented on 2019-12-31 15:41

@Kicer And you are right about the platform package. My version of this package has this dependency because it wouldn't build otherwise. I suppose the exact version which is required is determined by the platform version one configures Qt to target. Hence I'm using a variable in my PKGBUILD file for it.

By the way, the reason the master branch of my PKGBUILDs repo still has version 5.13 and not 5.14 is because of that CMake regression.

Martchus commented on 2019-12-31 15:34

@Kicer This is a known bug, see my comment on the aarch64 package.

Kicer commented on 2019-12-31 10:36

After update to Qt5.14 there is a lot of directories missing in /opt/android-libs/armv7a-eabi/lib/cmake/ (like Qt5Widgets or Qt5Network, but also many many others)

Kicer commented on 2019-12-31 08:54

I believe dependency to android-platform-22 should be added here, as without it package won't compile. Btw I cannot find information why exactly version 22 of platform is required. Is it described anywhere?

Martchus commented on 2019-10-22 21:55

By the way, the KDAB blog posts mentions the new build option -android-abis which is now required to keep things sane and simple.

Apparently my assertion about CMake is not correct: https://cristianadam.eu/20191012/building-multiple-configurations-with-cmake-in-one-go

This works because with Clang the same compiler executable can be used and the architecture is just an argument. Still, it sounds like shooting yourself in the foot. E.g. you also need to find all the dependencies for all theses configurations at the same time.

Martchus commented on 2019-10-22 21:38

Let's see how this will work out: https://www.qt.io/blog/aab-support-in-qt-for-android

For us it likely still makes most sense to keep the architectures distinct. This feature makes not much sense if only Qt's build system supports it but not the other of libraries one might need to deploy. Besides, adding further complexity to the build system sounds like shooting yourself in the foot to me. Maybe the same could be achieved using distinct builds for the architectures as well. But Qt is transitioning to CMake anyway which only supports targeting one platform at a time (as far as I know). So they will likely need to drop their hacks again anyways.