@SGaist
NO, both are 32bit.
Seems clearing the build dir and make again solved the problem!

Ok, thanks for the reply. It pointed me in the correct direction and after many failures I finally figured it out.
I guess you only learn when you need to dig deep.

The only thing I had to do was install the correct version of openSSL. Since it is my first time I had no idea what the letter actually meant, I picked the first build, which was version g, I had to install version n.

For all future wanderers, the only thing you need to do to make the client work is one of the two options:

Just copy ssleay32.dll and libeay32.dll to working directory OR Install the latest version and set PATH to the folder where the two dlls are located.

After that you can use QWebSocket without even knowing SSL exists. Just call:

QWebSocket socket; socket.open( QUrl("someaddress") );

And, when the dlls are found the warnings disappear.

That's it.

@mkre said in Android build issues with OpenSSL on 5.0/5.1:

@sierdzio Is there a guide for either of these two solutions? Running into this issue now for an APK I'm trying to build for an Android 5.0/5.1 device that uses QNetworkRequest to download files from the internet.

Option 2 (workaround) is described in the linkg @kviktor posted, just above your comment.

As for compiling Qt statically, look in Qt docs and output of ./configure --help. Please remember license (LGPL, GPL) limitations when compiling statically.

Hi and welcome to devnet,

Understand the licensing constraints of using a static build of Qt and be ready to abide by them Install an up to date version of OpenSSL (the system version is just too old) Install MariaDB Download Qt's source Read documentation about static building Pass the -openssl-linked as parameter to configure Pass -sql-mysql as parameter to configure Pass the -I and -L parameters as needed in order for Qt to find the MariaDB and OpenSSL libraries. Call make -jX where X is the number of cores of your machine multiplied by 2 plus 1. Go grab <insert favorite beverage> and look at your processors heating up Call make install Enjoy development

@ThirdStrand said in Force system QT libraries to use openssl libraries shipped with the application:

@JKSH One would do this to ensure that the libraries used are the proper libraries which are expected in the program. In much the same way as we deploy the appropriate versions of Qt libraries, why not use a KNOWN library when deploying the libssl and libcrypto libraries?

If you want to use known libraries in your app without the possibility of user interference you should probably use static libraries and not dynamic. Because even if the other libraries are not in the system path there is always at least one user who might want to exchange your library with another one - perhaps optimized for his computer ;) Had this a couple of times on windows with DLLs and a lot with java apps where users just replaced „outdated“ libraries.

This has become the bane of my existence, and I am here in search of WHY it will work when it is in QtCreator and NOT work when deployed with the EXACT same loaded library files.

I didn‘t see your used OS but I could imagine that Qt Creator uses LD_PRELOAD mechanism to ensure that the specific libs are loaded first. This at least should work an Linux, I don‘t know any trick for that on windows. AFAIK macOS offers a similar mechanism to Linux.

By way of venting, this old question gets some new life. I have seen many "answers" which usually consist of "The user should install....", which anyone who has ever actually deployed retail software knows is an absolute NIGHTMARE.

Witness ProtonVPN! This commercial application is deployed with a specific (v1.1.1j) set of OpenSSL libraries. Why? Because it is developed with that version and is tested with that version. Why opt to allow the end user to change the libraries and break your application at will? That's just self-defeating.

Still this doesn‘t prevent the user from changing the libs themselves. And given the fact that the build environment doesn‘t often change it might very well be that they will be shipping an „outdated“ version - because the app was developed with it - and tested. When I worked on Air Traffic Control Software we almost never updated our libraries - because they were „tested“.

As I said earlier: If you want to prevent user modification use static linking. This way the size of your deployed app will also shrink.
But be sure to check possible licensing restrictions.

@kfrosty Thank you! Did work for me too! :)

The problem with such an example is that it doesn't allow to replicate your problem correctly and triggers others that are not related to yours thus it's not possible to offer sensible help.

There's an initial release of the VS-AddIn here

Sure there is, just build qtbase statically then build only the modules you want by hand or exclude all the modules you don't want when calling configure.

@Chris-Kawa Sometimes you forget to update deploy dlls, in that case runtime vs compiletime versions in "about window" would be helpful.
Even if you use auto windeployqt command, you'll still need to copy other dlls (OpenSSL, etc) by hand, there you'll forget.

IIRC there was a renaming of the libraries of OpenSSL so you'll have to double check.

https://www.openssl.org/policies/releasestrat.html
"Minor releases that change the last digit, e.g. 1.0.1 vs. 1.0.2, can and are likely to contain new features, but in a way that does not break binary compatibility."

So I don't believe what "1.0.2d vs 1.0.2c" itself causes a problem.

@Ni.Sumi
I mean the compiler invocation, not the error (I saw the error in your first post). It should look something like this:

g++ -c -pipe -g -std=gnu++0x -Wall -W -D_REENTRANT -fPIC -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I../../myproject -I. -I../../../qt/qt-5.6/qtbase/include -I../../../qt/qt-5.6/qtbase/include/QtWidgets -I../../../qt/qt-5.6/qtbase/include/QtGui -I../../../qt/qt-5.6/qtbase/include/QtCore -I. -I../../../qt/qt-5.6/qtbase/mkspecs/linux-g++ -o somesource.o ../../myproject/somesource.cpp

/ I've taken it from g++, but you get the idea - the compile line, the call that compiles the offending source. /

Kind regards.

I am not involved in the encoding part. I did not write one single code for encoding. I get 3rd party XML files and i just want to decode them. To be very clear on this: I can't change the encoding, it is not my software, i do not develop it and i never had. I just got the source code for the de and encrypt part, so i may be able to import the XML files. I never wrote a single line VB code in my life. To be honest, i don't believe security is the issue, the developer just don't want anyone to be able to open it. That may not be an excuse for bad code but so far, i can't change it, i'm just happy now to be able to decode.

i still think there is simpler explanation for your issue.
The linker can't even find the lib file specified.
Are you really sure that the libs are in "C:\source\icu2\lib"? And not in a release/debug subfolder, etc.?

@mrjj no misunderstanding. It was the latter and both of your responses were equally helpful.

@Leonardo said:

Linkage is done from right to left. Maybe you're adding your static library after openssl. Put it before.
Yes, you're right. Moving static library after openssl solved my issue.

@Dooms said:

sslConfiguration

You don't seem to have actually associated the sslConfiguration object with the QSslSocket object.

You can set the cert/key files directly on the QSslSocket if that helps simplify your code for testing...

@SGaist thanks for reply) I understand that I need that for deployment on device but I am building just qt not an app. So i thought it might be unnecessary for building Qt itself. Cause when i am downloading qt for Ios i don't need to have that account. But i need it to build qt that's strange for me. I have ready code to port to ios so openssl is needed

@koahnig I am using 2.0.1