Qt6 Static Cross Compile with OpenSSL

squinky86

@SGaist said in Qt6 Static Cross Compile with OpenSSL:

Did you check the configure log files to see exactly what failed in the OpenSSL tests ?

I've been slowly tracking this down more and more thanks to the error logs. It appears that the OpenSSL check uses the platform's C++ compiler rather than the cross compiler I'm configuring Qt to use. This appears, to me, to be a bug - when the cross compile device option is selected, the OpenSSL linking check should use the cross compiler.

Pease note that I had to set up a VM on another computer, so the directory structure has moved from /home/me to /home/jon/w64 for openssl and Qt 6.3.0 RC. I've also been trying this with OpenSSL 1.1.1n and OpenSSL 3.0.2 with the same results.

Performing C++ SOURCE FILE Test HAVE_openssl failed with the following output:
Change Dir: /home/jon/w64/qtbase-everywhere-src-6.3.0-rc/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_30003/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_30003.dir/build.make CMakeFiles/cmTC_30003.dir/build
gmake[1]: Entering directory '/home/jon/w64/qtbase-everywhere-src-6.3.0-rc/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_30003.dir/src.cxx.o
/usr/bin/c++  -isystem /home/jon/w64/openssl-3.0.2/include -DHAVE_openssl -fPIE -std=gnu++17 -o CMakeFiles/cmTC_30003.dir/src.cxx.o -c /home/jon/w64/qtbase-everywhere-src-6.3.0-rc/CMakeFiles/CMakeTmp/src.cxx
Linking CXX executable cmTC_30003
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_30003.dir/link.txt --verbose=1
/usr/bin/c++  -DHAVE_openssl CMakeFiles/cmTC_30003.dir/src.cxx.o -o cmTC_30003  /home/jon/w64/openssl-3.0.2/libssl.a /home/jon/w64/openssl-3.0.2/libcrypto.a -ldl
/usr/bin/ld: /home/jon/w64/openssl-3.0.2/libssl.a(libssl-lib-ssl_lib.obj):ssl_lib.c:(.text+0x650): undefined reference to `__mingw_vsprintf'
/usr/bin/ld: /home/jon/w64/openssl-3.0.2/libssl.a(libssl-lib-ssl_lib.obj):ssl_lib.c:(.text+0x6bdc): undefined reference to `__imp__time64'
/usr/bin/ld: /home/jon/w64/openssl-3.0.2/libssl.a(libssl-lib-ssl_sess.obj):ssl_sess.c:(.text+0x857): undefined reference to `__imp__time64'
/usr/bin/ld: /home/jon/w64/openssl-3.0.2/libssl.a(libssl-lib-ssl_sess.obj):ssl_sess.c:(.text+0x1497): undefined reference to `__imp__time64'
/usr/bin/ld: /home/jon/w64/openssl-3.0.2/libssl.a(libssl-lib-ssl_sess.obj):ssl_sess.c:(.text+0x1a8a): undefined reference to `__imp__time64'
...

Now that I understand what's going wrong, I'm struggling trying to figure out how to get the Qt configure system to pass the mingw cross compiler to this check rather than /usr/bin/c++.

SGaist

Sounds fishy indeed.

Can you share the configuration line you use ?

squinky86

@SGaist said in Qt6 Static Cross Compile with OpenSSL:

Sounds fishy indeed.

Can you share the configuration line you use ?

They are in the original post.

OpenSSL configure: ./Configure mingw64 no-shared no-asm no-err no-tests CROSS_COMPILE=x86_64-w64-mingw32-

Qt 6.3.0 configure (note, this time I'm using an unsupported cmake, but the error was the same with an upgraded cmake installed with snap or if I use openssl-1.1.1n): ./configure -platform linux-g++-64 -qt-host-path /opt/qt6.3-static -xplatform win32-g++ -device-option CROSS_COMPILE=x86_64-w64-mingw32- -release -opengl desktop -mp -static -static-runtime -no-shared -nomake examples -no-icu -optimize-size -openssl-linked -- -DQT_FORCE_MIN_CMAKE_VERSION_FOR_BUILDING_QT=3.18 -DOPENSSL_ROOT_DIR=/home/jon/w64/openssl-3.0.2

SGaist

Nothing stands out as wrong with the options you use.

You may have found an issue with the win32 cross-compilation.

squinky86

I filed a QTBUG and @Croitor-Alexandru patiently pointed me towards needing to specify the cmake profile as well when configuring a cross compile. Qt6 configured correctly (though it's still not building) with his input.

Missing option: "-DCMAKE_TOOLCHAIN_FILE=/home/jon/w64/profile.cmake" where profile.cmake is the same one I use for everything. Just in case anyone comes here from google, here's the profile that mostly worked (you can probably drop the Fortran compiler, but I at least know this works and don't feel like testing without it).

set(CMAKE_SYSTEM_NAME Windows)
set(TOOLCHAIN_PREFIX x86_64-w64-mingw32)
set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}-gcc)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}-g++)
set(CMAKE_Fortran_COMPILER ${TOOLCHAIN_PREFIX}-gfortran)
set(CMAKE_RC_COMPILER ${TOOLCHAIN_PREFIX}-windres)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH /usr/x86_64-w64-mingw32)

That gets through the configure, but the build fails pretty hard in the Gui target. I'm going to try some things (update cmake, switch to ninja, etc.) and create another thread in these forums if I can't figure it out on my end.

EDIT: Got it working with no additional modifications using cmake 3.18 and regular Makefiles.

SGaist

Thanks for the detailed feedback !

Can you share the bug url ? That may be useful for other people.

squinky86

@SGaist said in Qt6 Static Cross Compile with OpenSSL:

Thanks for the detailed feedback !

Can you share the bug url ? That may be useful for other people.

QTBUG-102250

I now have Qt6 cross compiled and working. Some of my slots and signals are not working, but I'm slowly figuring it out.

EDIT: Slots and signals are now fixed. Qt5 gave me some overloaded interfaces that I wasn't supposed to be using. Switching those over resulted in successful unit tests! Once I get appveyor set up for my nightly builds, I'll be 100% ported over to Qt6 thanks to everyone's help here.

rightec

@SGaist Hello
if it possible i would like some more explanation about the config command.
If i read " -openssl-linked --" I imagine that openSSL support is already been built against the cross compiler and
the result of building lays on the folder indicated by -DOPENSSL_ROOT_DIR=/home/jon/w64/openssl-3.0.2. (in this example)
But what about the native QT openSsl support that we have in "qtbase/src/plugins/tls/openssl" ?
How can we include it in the cross compilation?

My question rises from an error that i got compilig a websocket QT project against arm32:
error: ‘class QWebSocket’ has no member named ‘ignoreSslErrors’
96 | m_webSocket.ignoreSslErrors();

Thanks for answering
Regards
FM

SGaist

@rightec hi,

OpenSSL linked means that the backend is directly linked against OpenSSL. The plugins/tls/openssl folder is that backend.

If you have the support missing, then it means that the detection somehow failed. Check the cmake logs to see what exactly failed.

rightec

@SGaist Hello
First of all, thank you for your clarification
I was able to compile correctly after downloading the openSSL source code from git (OpenSSL_1_1_1-stable branch) and building it against the cross compiler.
Building process seems ok now, but at run time the qt sample sslechoclient returns me the following:

./sslechoclient.sh
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation

That sounds me strange. The OpenSSL version i've cross-compiled is 1.1.1t, the version i got on my Ubuntu host system is 1.1.1f. That is the only difference.
Do you have any idea?

QT is 6.2.4 on both target and host
Thanks
Regards
FM

rightec

@rightec said in Qt6 Static Cross Compile with OpenSSL:

Active TLS backend does not support key creation

I solved compiling openSSL 111f on the target

SGaist

@rightec any chances you built OpenSSL for your host rather than your target ?

rightec

@SGaist I did not try. BTW host is 64 bit and target 32.

SGaist

The fact that it's a 32 bit target is not an issue. Depending on the library, the harder is often to make its build system use the cross-compiler on the host (things have vastly improved on that side since I was doing embedded work).