Arch Linux User Repository

@tomicooler no, that's not a good solution, I've tried and it breaks aarch64 build, and it compile and install arm64-v8a files inside armv7a-eabi folder. Better insist with that bug to be fixed.

There is a workaround for the CMake build.

-        -android-abis ${ANDROID_ABI}
+        -android-abis ${ANDROID_ABI},${ANDROID_ABI}

I followed Cristian Adam's comment in QTBUG-80938.

I don't use CMake so I didn't checked it. But if you have any patches that solve that problem I will include them in the PKGBUILD.

You've been updating to 5.14.1. Have you had any luck with CMake so far? On their issue tracker the absence of CMake config files is still in the status 'reported' so I haven't tried to out 5.14.1 myself yet.

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

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.

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.

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.

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.

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.