@SherifOmran said in how to compile qt static with open ssl:

PATH

If you really need to change that variable, then do it only in the terminal you use to build your stuff. It's never a good idea to add the path to such sensitive libraries system wide as you might break unrelated applications.

sample of script:

#!/bin/bash # Cross-compile environment for Android on ARMv7 and x86 # # Contents licensed under the terms of the OpenSSL license # http://www.openssl.org/source/license.html # # See http://wiki.openssl.org/index.php/FIPS_Library_and_Android # and http://wiki.openssl.org/index.php/Android ##################################################################### export ANDROID_NDK_ROOT="/c/ASHISH/android-ndk-r15c" # Set ANDROID_NDK_ROOT to you NDK location. For example, # /opt/android-ndk-r8e or /opt/android-ndk-r9. This can be done in a # login script. If ANDROID_NDK_ROOT is not specified, the script will # try to pick it up with the value of _ANDROID_NDK_ROOT below. If # ANDROID_NDK_ROOT is set, then the value is ignored. # _ANDROID_NDK="android-ndk-r8e" #_ANDROID_NDK="android-ndk-r9" # _ANDROID_NDK="android-ndk-r10" # Set _ANDROID_EABI to the EABI you want to use. You can find the # list in $ANDROID_NDK_ROOT/toolchains. This value is always used. # _ANDROID_EABI="x86-4.6" # _ANDROID_EABI="arm-linux-androideabi-4.6" _ANDROID_EABI="arm-linux-androideabi-4.9" # Set _ANDROID_ARCH to the architecture you are building for. # This value is always used. # _ANDROID_ARCH=arch-x86 _ANDROID_ARCH=arch-arm # Set _ANDROID_API to the API you want to use. You should set it # to one of: android-14, android-9, android-8, android-14, android-5 # android-4, or android-3. You can't set it to the latest (for # example, API-17) because the NDK does not supply the platform. At # Android 5.0, there will likely be another platform added (android-22?). # This value is always used. # _ANDROID_API="android-14" _ANDROID_API="android-24" # _ANDROID_API="android-19" ##################################################################### # If the user did not specify the NDK location, try and pick it up. # We expect something like ANDROID_NDK_ROOT=/opt/android-ndk-r8e # or ANDROID_NDK_ROOT=/usr/local/android-ndk-r8e. if [ -z "$ANDROID_NDK_ROOT" ]; then _ANDROID_NDK_ROOT="" if [ -z "$_ANDROID_NDK_ROOT" ] && [ -d "/usr/local/$_ANDROID_NDK" ]; then _ANDROID_NDK_ROOT="/usr/local/$_ANDROID_NDK" fi if [ -z "$_ANDROID_NDK_ROOT" ] && [ -d "/opt/$_ANDROID_NDK" ]; then _ANDROID_NDK_ROOT="/opt/$_ANDROID_NDK" fi if [ -z "$_ANDROID_NDK_ROOT" ] && [ -d "$HOME/$_ANDROID_NDK" ]; then _ANDROID_NDK_ROOT="$HOME/$_ANDROID_NDK" fi if [ -z "$_ANDROID_NDK_ROOT" ] && [ -d "$PWD/$_ANDROID_NDK" ]; then _ANDROID_NDK_ROOT="$PWD/$_ANDROID_NDK" fi # If a path was set, then export it if [ ! -z "$_ANDROID_NDK_ROOT" ] && [ -d "$_ANDROID_NDK_ROOT" ]; then export ANDROID_NDK_ROOT="$_ANDROID_NDK_ROOT" fi fi # Error checking # ANDROID_NDK_ROOT should always be set by the user (even when not running this script) # http://groups.google.com/group/android-ndk/browse_thread/thread/a998e139aca71d77 if [ -z "$ANDROID_NDK_ROOT" ] || [ ! -d "$ANDROID_NDK_ROOT" ]; then echo "Error: ANDROID_NDK_ROOT is not a valid path. Please edit this script." # echo "$ANDROID_NDK_ROOT" # exit 1 fi # Error checking if [ ! -d "$ANDROID_NDK_ROOT/toolchains" ]; then echo "Error: ANDROID_NDK_ROOT/toolchains is not a valid path. Please edit this script." # echo "$ANDROID_NDK_ROOT/toolchains" # exit 1 fi # Error checking if [ ! -d "$ANDROID_NDK_ROOT/toolchains/$_ANDROID_EABI" ]; then echo "Error: ANDROID_EABI is not a valid path. Please edit this script." # echo "$ANDROID_NDK_ROOT/toolchains/$_ANDROID_EABI" # exit 1 fi ##################################################################### # Based on ANDROID_NDK_ROOT, try and pick up the required toolchain. We expect something like: # /opt/android-ndk-r83/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin # Once we locate the toolchain, we add it to the PATH. Note: this is the 'hard way' of # doing things according to the NDK documentation for Ice Cream Sandwich. # https://android.googlesource.com/platform/ndk/+/ics-mr0/docs/STANDALONE-TOOLCHAIN.html ANDROID_TOOLCHAIN="" for host in "linux-x86_64" "linux-x86" "darwin-x86_64" "darwin-x86" "windows-x86_64" do if [ -d "$ANDROID_NDK_ROOT/toolchains/$_ANDROID_EABI/prebuilt/$host/bin" ]; then ANDROID_TOOLCHAIN="$ANDROID_NDK_ROOT/toolchains/$_ANDROID_EABI/prebuilt/$host/bin" break fi done # Error checking if [ -z "$ANDROID_TOOLCHAIN" ] || [ ! -d "$ANDROID_TOOLCHAIN" ]; then echo "Error: ANDROID_TOOLCHAIN is not valid. Please edit this script." # echo "$ANDROID_TOOLCHAIN" # exit 1 fi case $_ANDROID_ARCH in arch-arm) ANDROID_TOOLS="arm-linux-androideabi-gcc arm-linux-androideabi-ranlib arm-linux-androideabi-ld" ;; arch-x86) ANDROID_TOOLS="i686-linux-android-gcc i686-linux-android-ranlib i686-linux-android-ld" ;; *) echo "ERROR ERROR ERROR" ;; esac for tool in $ANDROID_TOOLS do # Error checking if [ ! -e "$ANDROID_TOOLCHAIN/$tool" ]; then echo "Error: Failed to find $tool. Please edit this script." # echo "$ANDROID_TOOLCHAIN/$tool" # exit 1 fi done # Only modify/export PATH if ANDROID_TOOLCHAIN good if [ ! -z "$ANDROID_TOOLCHAIN" ]; then export ANDROID_TOOLCHAIN="$ANDROID_TOOLCHAIN" export PATH="$ANDROID_TOOLCHAIN":"$PATH" fi ##################################################################### # For the Android SYSROOT. Can be used on the command line with --sysroot # https://android.googlesource.com/platform/ndk/+/ics-mr0/docs/STANDALONE-TOOLCHAIN.html export ANDROID_SYSROOT="$ANDROID_NDK_ROOT/platforms/$_ANDROID_API/$_ANDROID_ARCH" export CROSS_SYSROOT="$ANDROID_SYSROOT" export NDK_SYSROOT="$ANDROID_SYSROOT" # Error checking if [ -z "$ANDROID_SYSROOT" ] || [ ! -d "$ANDROID_SYSROOT" ]; then echo "Error: ANDROID_SYSROOT is not valid. Please edit this script." # echo "$ANDROID_SYSROOT" # exit 1 fi ##################################################################### # If the user did not specify the FIPS_SIG location, try and pick it up # If the user specified a bad location, then try and pick it up too. #if [ -z "$FIPS_SIG" ] || [ ! -e "$FIPS_SIG" ]; then # # # Try and locate it # _FIPS_SIG="" # if [ -d "/usr/local/ssl/$_ANDROID_API" ]; then # _FIPS_SIG=`find "/usr/local/ssl/$_ANDROID_API" -name incore` # fi # # if [ ! -e "$_FIPS_SIG" ]; then # _FIPS_SIG=`find $PWD -name incore` # fi # # # If a path was set, then export it # if [ ! -z "$_FIPS_SIG" ] && [ -e "$_FIPS_SIG" ]; then # export FIPS_SIG="$_FIPS_SIG" # fi #fi ## Error checking. Its OK to ignore this if you are *not* building for FIPS #if [ -z "$FIPS_SIG" ] || [ ! -e "$FIPS_SIG" ]; then # echo "Error: FIPS_SIG does not specify incore module. Please edit this script." # # echo "$FIPS_SIG" # # exit 1 #fi ##################################################################### # Most of these should be OK (MACHINE, SYSTEM, ARCH). RELEASE is ignored. export MACHINE=armv7 export RELEASE=2.6.37 export SYSTEM=android export ARCH=arm export CROSS_COMPILE="arm-linux-androideabi-" if [ "$_ANDROID_ARCH" == "arch-x86" ]; then export MACHINE=i686 export RELEASE=2.6.37 export SYSTEM=android export ARCH=x86 export CROSS_COMPILE="i686-linux-android-" fi # For the Android toolchain # https://android.googlesource.com/platform/ndk/+/ics-mr0/docs/STANDALONE-TOOLCHAIN.html export ANDROID_SYSROOT="$ANDROID_NDK_ROOT/platforms/$_ANDROID_API/$_ANDROID_ARCH" export SYSROOT="$ANDROID_SYSROOT" export NDK_SYSROOT="$ANDROID_SYSROOT" export ANDROID_NDK_SYSROOT="$ANDROID_SYSROOT" export ANDROID_API="$_ANDROID_API" # CROSS_COMPILE and ANDROID_DEV are DFW (Don't Fiddle With). Its used by OpenSSL build system. # export CROSS_COMPILE="arm-linux-androideabi-" export ANDROID_DEV="$ANDROID_NDK_ROOT/platforms/$_ANDROID_API/$_ANDROID_ARCH/usr" export HOSTCC=gcc VERBOSE=1 if [ ! -z "$VERBOSE" ] && [ "$VERBOSE" != "0" ]; then echo "ANDROID_NDK_ROOT: $ANDROID_NDK_ROOT" echo "ANDROID_ARCH: $_ANDROID_ARCH" echo "ANDROID_EABI: $_ANDROID_EABI" echo "ANDROID_API: $ANDROID_API" echo "ANDROID_SYSROOT: $ANDROID_SYSROOT" echo "ANDROID_TOOLCHAIN: $ANDROID_TOOLCHAIN" echo "FIPS_SIG: $FIPS_SIG" echo "CROSS_COMPILE: $CROSS_COMPILE" echo "ANDROID_DEV: $ANDROID_DEV" fi

Hi,

Not the same backend used. Unless you re-build Qt and force the use of OpenSSL. Qt on macOS uses Apple's SecureTransport framework. OpenSSL on that platform has been deprecated a long time ago.

@Opa114 Thanks for the feedback. So please mark this topic as SOLVED now.

It wooooorked, thank you so muuuuch :)

@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.

For anyone finding this thread via Google OpenSSL actually has a somewhat detailed description about the workaround: https://wiki.openssl.org/index.php/Android#Wrapper_Shared_Objects

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

Hi, and welcome to the Qt Dev Net!

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

Can I force QT libraries to somehow use openssl shipped along with my application?

May I ask why you want to do that?

OpenSSL is a security library. Old versions can contain known, exploitable security holes, so it sounds like a good idea to use the latest version whenever it's available. This way, when the end user upgrades OpenSSL on their system, your Qt application will automatically pick up the new OpenSSL.

@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

Thanks, -no-openssl -securetransport works. Now I can use Mac OS X native secure transport instead of OpenSSL.

For the people googleing this issue. There is documentation abut this in
qtbase/src/network/ssl/ssl.pri:

Add optional SSL libs # Static linking of OpenSSL with msvc: # - Binaries http://slproweb.com/products/Win32OpenSSL.html # - also needs -lUser32 -lAdvapi32 -lGdi32 -lCrypt32 # - libs in <OPENSSL_DIR>\lib\VC\static # - configure: -openssl -openssl-linked -I <OPENSSL_DIR>\include -L <OPENSSL_DIR>\lib\VC\static OPENSSL_LIBS="-lUser32 -lAdvapi32 -lGdi32" OPENSSL_LIBS_DEBUG="-lssleay32MDd -llibeay32MDd" OPENSSL_LIBS_RELEASE="-lssleay32MD -llibeay32MD"

Just to be sure: it fails to build on Windows even if you use one of the official package ?

@mcosta Thanks mcosta

Yes, indeed I can show website over https with WebEngine, even though it still show those warning messages. As documented here, Web Kit will be deprecated in Qt version 5.5+, so I'll switch to use WebEngine then.

For those who feel annoyed with the warning messages, you could suppress them by calling following method in your main()

QLoggingCategory::setFilterRules("qt.network.ssl.w arning=false");

or by setting environment variable

QT_LOGGING_RULES=qt.network.ssl.warning=false

Do you have the simulator installed ?

It's because Qt (or rather QSslSocket) closes the connection immediately after emitting the error() signal.

@Jeff-Andle
A list of vulnerabilities can be found here . From the list i can take that it's one MITM exploit and everything else just DOS. Also google just warns us about a possible problem, it doesn't remove nor unpublish the app. Afaik heartbleed occurs from OpenSSL version 1.0.1 to 1.0.1f until it's fix in version 1.0.1g. So version 1.0.0e shouldn't have a problem with heartbleed. Although i would like to update somehow anyway...

I was able to upgrade the version of OpenSSL by using the Qt MaintenanceTool.exe and updating everything to the latest. Have yet to submit to Google, but I think it may be the solution.

Oh, I guess when not using -openssl-linked, it will not matter as the .lib files will not be used.
I'm still interested in what to do if I'd actually want to use -openssl-linked.

Try to install the latest OpenSSL libraries for Windows. You can find it here : https://www.openssl.org/related/binaries.html