Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
library "libssl.so.1.1" not found
i have built the Qt Source Code (Qt 5.12.9) and have linked to openssl version 1.1.1d on MAC and it has built correctly.
This is my configure command
OPENSSL_LIBS='-L/Users/shriup/Documents/Qt-SourceBuild/qt-android/armeabi-v7a/android-arm -lssl -lcrypto' ./configure -xplatform android-clang --disable-rpath -nomake tests -nomake examples -android-ndk /Users/shriup/Documents/Qt-SourceBuild/qt-android/qt-everywhere-src-5.12.9/android-ndk-r21d -android-sdk /Users/shriup/Documents/Qt-SourceBuild/qt-android/qt-everywhere-src-5.12.9/sdk -android-ndk-host darwin-x86_64 -skip qttranslations -skip qtserialport -openssl-linked -I/Users/shriup/Documents/Qt-SourceBuild/qt-android/openssl-1.1.1d/include -no-warnings-are-errors -opensource -confirm-license -prefix /Users/shriup/QtWebAndroidSSLC
And I have a created a sample dummy android app with the KIT configured. The app is building fine and also gets deployed successfully, but crashes as soon as it launches.
This is the error which it gives
On Android, if you are using dynamic linking, you should link OpenSSL to your app, not to Qt. Just put your open ssl libs inside
android/libsdirectory (separate subdirs per architecture) and it will work with stock (prebuilt) Qt from Qt Installer.
And use the newest OpenSSL. Always! 1.1.1d is old, newest is 1.1.1g.
Okay, I have built the Qt source code with OpenSSL 1.1.1g also, but iam getting the same error there also. I have added the libs also to the app.
There is no need to add them to .pro file and no need to compile Qt with them.
But anyway, notice the error message: it looks for
libssl.so.1.1but you provide
libssl.so(your files do not have
Okay, but the libs folder has both the files libssl.so and libssl.so.1.1 .
I suspect the error comes from your Qt compilation, maybe it tries to load OpenSSL before the code from your app is reached.
Ohh okay, but any ideas how I can debug this and check where is this mismatch happening and all.
I don't know, sorry.
Just to throw out a couple things that I would try if I were in this predicament:
- unzip the APK (or AAB) and make sure it contains the libs you expect
- assuming you are happy with step (1), then make sure the libs are built for the right architecture
- if (1) and (2) look good, then there must be some extra step (maybe involving the Manifest) needed to tell the Java android runtime which paths to search when attempting dlopen.
It might seem like my suggestion number (2) -- check the architecture -- is unnecessary because you would think "well, if compilation and linking succeeded, then I can assume that libssl is for the proper architecture." However, I can imagine an edge case where something in your build toolchain (either on the qmake side or the android side or elsewhere) built several versions of libssl for varying architectures, and the one that was used at link time was overwritten in the APK by another one. That would definitely be an extreme edge case, but there is some slim chance.
At the end of the day since the problem only happens after deployment to a device, you have to inspect the artifacts that are getting onto the device, which is the APK or AAB.
HemantSuryawanshi last edited by
try by adding https://github.com/KDAB/android_openssl these files in your project. also add those files in your .pro file.
Shrinidhi Upadhyaya last edited by Shrinidhi Upadhyaya
How can I add libssl.so.1.1 and libcrypto.so.1.1, I cannot add them via Qt Project Settings or even if I try to by editing the .pro filet gives me a error that a "External File Library should start with lib and end with .so"
Hi @HemantSuryawanshi, thanks a lot for the link, but that is for building Openssl right, I have built openssl and linked with Qt source code and its working fine, its just that the app is not getting deployed.
I'm happy you were able to discover something by unzipping the apk.
The fact that you found the "numberless" binaries present for "libssl.so" and "libcrypto.so" seems promising to me. That makes it seem that Sierdzio had the right idea earlier when he pointed out that "it looks for libssl.so.1.1 but you provide libssl.so"
WARNING: I am operating at the very edge of my (limited) knowledge of Qt for Android... so take everything I say and run in through your own "fact checking" please...
It seems like when you compile and link, the linking is using the numbered "libssl.so.1.1", but when things are packaged into the APK the packaging tools are grabbing the numberless libssl.so
So one idea I have is that wherever your "original" copies of armeabi-v7a are... wherever they sit on your development PC... just go in there (seems to be a folder you named "android/libs/armeabi-v7a/") and DELETE all but one unique way to "see" libssl. Either delete the numbered symlinks, or rename the actual binary lib to have a numbered name, and delete the numberless one. Then do full a full clean, then retry. It seems to me that if ALL YOU HAVE ON DISK is just one "name" for these so libs, then both the linker and the packager will be forced to use the same name.
If this were a Linux desktop app then I might feel more cautious about removing the "1.1" version numbers, because someone might be at risk of installing your app and running it and loading the wrong version of libssl.
But since this is an APK where all the libs are packaged with your app and not reused by anything else, it seems more acceptable to me to remove version numbers from the files as long as you keep track of what you did and why.
Hopefully someone will correct me if this is bad advice.
Shrinidhi Upadhyaya last edited by Shrinidhi Upadhyaya
Hi @KH-219Design , thanks a lot for your quick response, but the thing is just consider your build output folder which has several folders called assets, src, res, libs & Gradle and few other files. So if you go into the libs folder you will see all the libs(.so), which gets replaced completely every time you build your app or even just deploy. So deleting or just copy pasting the libssl.so.1.1 won't work. So my question is every time the app is building fine and even getting deployed but once it gets deployed it crashes at runtime because it cannot find the libssl.so.1.1 . Can I get to know from which part of the code does it look for libssl.so.1.1 or even if you want I can build the Qt Source Code once again, if I had made some mistake while configuring which makes it take libssl.so.1.1. I have posted my configure command above in the first comment.
@Shrinidhi-Upadhyaya Oh. I'm sorry. I failed to understand that this "libs" folder where the numbered symlinks appear is getting recreated by Gradle (or by something) during each build. You are right that my advice is not helpful in light of that fact.
I'll let you know if I think of any other ideas. The Android Qt apps I have built so far had no dependencies on any libraries other than Qt's own libraries.
I asked a co-worker if he had any ideas on this topic, and here are a few thoughts he came up with:
You could try to unzip the APK, copy libssl to "libssl.so.1.1.", then re-zip and try to install the rezipped APK to an Android device. (We are unsure if this would invalidate any kind of Android signature or checksum relating to the original APK, though. If so, the device might reject the APK.)
Another thought (that maybe leads to more tailored Google searches?): "I know in the Qt Creator settings a few versions back there was a special setting for Android OpenSSL but I don't know which versions that was the case or why."
When you have the APK unzipped, locate the "so" that represents the Qt App, and run
readelf, like so:
readelf --dynamic lib/armeabi-v7a/libYourQtAppName_armeabi-v7a.so # replace "YourQtAppName" appropriately
You can also then run
readelfon other "*so" files in your APK (even the Qt ones), and see if maybe any surprise you by also depending on libssl.
This could reveal that maybe something else is requiring "libssl" that you were unaware of, and maybe your main app project isn't even the principal cause of this issue.
My co-worker also brought up the issue of correct architectures again (which was something I called out in my original reply).
I was concerned that maybe the "*so" didn't contain machine code for the right architecture. My co-worker reminded me that also sometimes the issue is not having the "*so" in the right subdirectory for its intended architecture. These are his words verbatim:
I do remember having an issue with handling multiple architectures in packaging where I had to add things like "_armeabi-v7a" for the arch to the end of the so binary to have Qt automatically assign it to the right architecture folder.
I'm sorry I don't have any definitive solution. I hope when you solve this you will post back here and let us all know what the ultimate solution is!
Something else that I always recommend is to search through the Qt examples (I download Qt sources and locate all folders named "examples") and try to learn how the examples achieve various things.
I just searched in "qtandroidextras/examples/", but I did not find any Android sample projects with SSL.
I also just found this page: https://doc.qt.io/qt-5/android-openssl-support.html
... but you'll have to judge whether any of that applies to your project.
Just build OpenSSL without the
1.1extension, put it in
libsfolder (not after build, the one inside your source tree) or use ANDROID_EXTRA_LIBS, and it will work.
If you analyze the KDAB's script, you'll notice they are building without
Okay Finally solved by building OpenSSL with SHLIB_VERSION_NUMBER = .so and then linking it with Qt and finally building the Qt Source Code.
Nice, happy coding!