Package Details: android-armv7a-eabi-qt5 5.14.0-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: hipersayan_x
Last Packager: hipersayan_x
Votes: 19
Popularity: 1.49
First Submitted: 2018-11-22 19:15
Last Updated: 2020-01-19 17:30

Dependencies (26)

Sources (4)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

Martchus commented on 2020-01-18 15:42

I updated the OpenSSL package: https://github.com/Martchus/PKGBUILDs/commit/9a91bb20cc0a008784b2b8b30afd7e2aab9f7bf3
I also added symlinks so hopefully other build systems will still be able to pick up the libraries: https://github.com/Martchus/PKGBUILDs/commit/42324a6d46a0d339d3abad70e9acd4fdafd1c65b

Martchus commented on 2020-01-18 03:57

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

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

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

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

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

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

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

Using static libraries may be against Qt's license.

hipersayan_x commented on 2020-01-10 00:21

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