Package Details: android-armv7a-eabi-qt5 5.15.2-2

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: None
Last Packager: hipersayan_x
Votes: 18
Popularity: 0.000000
First Submitted: 2018-11-22 19:15 (UTC)
Last Updated: 2021-03-14 20:02 (UTC)

Dependencies (26)

Sources (4)

Pinned Comments

hipersayan_x commented on 2021-07-07 15:06 (UTC) (edited on 2021-07-07 15:10 (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 .. 12 Next › Last »

Martchus commented on 2020-01-18 03:57 (UTC)

Reading Qt' SSL code it likely works if we call them libssl_1_1.so and libcrypto_1_1.so. Otherwise one could set the environment variable ANDROID_OPENSSL_SUFFIX for a custom suffix. I'll change the OpenSSL package when I have the time.

Martchus commented on 2020-01-18 03:42 (UTC) (edited on 2020-01-18 03:43 (UTC) by Martchus)

Oh, after reading the error again it seems like it actually would try to load it using the usual name. I assume that problem came with increasing the Android target to 24 then? Maybe we should then indeed rename the library. Unfortunately that means we need to ensure that Qt will load it under that name and other libraries which make use of OpenSSL need to be adjusted, too.

Martchus commented on 2020-01-18 03:34 (UTC)

So the multi ABI build also broke loading OpenSSL (which worked before). I'd rather patch Qt than and other library which is using OpenSSL. Maybe it also helps to set Qt's OpenSSL configuration to linked.

hipersayan_x commented on 2020-01-17 22:01 (UTC) 

E linker  : library "/system/lib/libcrypto.so" ("/system/lib/libcrypto.so") needed or dlopened by "/data/app/org.webcamoidprj.webcamoid-5CLAWu48ijiY_uUdzlZeBg==/lib/x86_64/libQt5Core_x86_64.so" is not accessible for the namespace: [name="classloader-namespace", ld_library_paths="", default_library_paths="/data/app/org.webcamoidprj.webcamoid-5CLAWu48ijiY_uUdzlZeBg==/lib/x86_64:/system/fake-libs64:/data/app/org.webcamoidprj.webcamoid-5CLAWu48ijiY_uUdzlZeBg==/base.apk!/lib/x86_64", permitted_paths="/data:/mnt/expand:/data/data/org.webcamoidprj.webcamoid"]

As said before, linking to libraries that are already included internaly in Android seems to be a bad idea. Also, I've checked and its't included in the bundle, so maybe it's complaining because it's trying to load the library from the system and it can't? Maybe adding a suffix to the library (like Qt does) would solve the problem? for example: libcrypto_x86_64.so.

Martchus commented on 2020-01-10 18:36 (UTC)

then what guarantees us they are not using any library we are shipping and users need for their apps?

I've asked myself the same question and I suppose the answer is absolutely nothing. Hence they've implemented "Namespaces for Native Libraries" with Android 7. That's the "official" solution and the only problem with it is that it is only available on Android 7 or later.

I would also vote for 2). The 80 % market share will increase in the further. So the problem will solve itself (even if it might take a while).

Note that this doesn't outrule option 1) for anybody else. It shouldn't be hard to create an alternative variant of this package to build with a minimum of external dependencies if somebody requires it and thinks it is worth the effort considering the advantages and disadvantages.

hipersayan_x commented on 2020-01-10 14:27 (UTC) (edited on 2020-01-10 14:28 (UTC) by hipersayan_x)

Ok reading the comment again, the only library we are providing (or at least in my case) that may conflict is zlib.
I've searched for libcrypto.so and it's nowhere in the NDK tree, and private libraries are not referenced anywhere in the documentation, then what guarantees us they are not using any library we are shipping and users need for their apps?
And there is the license problem, what if someone want to distribute their apps under BSD but it need to be linked against a LGPL library? then it can't be statically linked. That bug is an Android fault, and Android developers are the only responsible for that. Then I see two solutions:

1) Disable all dependencies if platform < 24, which absolutely invalidate all the environment we are trying to build, or
2) Increase ANDROID_MINIMUM_PLATFORM to 24 (Android 7), in which case you cover 80% of the marketshare more or less, and increasing. And everyone that want to develop for older platforms are on their own.

For me, option 2) is the ockham solution to the problem.

Martchus commented on 2020-01-10 09:54 (UTC)

My current use-case would be distributing an app which is GPL itself so I suppose it would be ok. But generally licensing can be problematic of course.

But like I said: I wouldn't underestimate the technical difficulties of making a fully statically linked build because that's likely not well tested/supported by Qt when targeting Android. At least when targeting Windows/mingw-w64 it requires for instance several workarounds (although the situation is getting better).

Kicer commented on 2020-01-10 09:38 (UTC)

Using static libraries may be against Qt's license.

hipersayan_x commented on 2020-01-10 00:21 (UTC)

Shared libraries are not shared by other apks anyways, so statically compiling everything would be a solution. Then, we go for that?

Martchus commented on 2020-01-09 11:36 (UTC) (edited on 2020-01-09 11:38 (UTC) by Martchus)

Alexey made a good point on Qt's issue tracker that bundling/using shared libraries such as OpenSSL as we do it here is actually dangerous under Android < 7. So this way of building and bundling Qt and other dependencies is only working on Android 7 and above which resolves this problem. I could also reproduce that an app using OpenSSL crashes on an old SG4 with Android 5.

I don't know a way to conveniently workaround the problem. The options described in the OpenSSL wiki are a bit cumbersome, especially making a shared wrapper. But also linking the shared Qt libs statically against OpenSSL isn't nice when other dependencies or the app itself are using OpenSSL directly. The obvious solution would be to link against all dependencies statically (requiring a static Qt build). That's what I'm doing under Windows. However, it is also quite some effort to make this work (especially since it doesn't look like Qt would support that at all under Android). Likely it is the best to simply ignore the problem and require users to have at least Android 7.

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