qt.network.ssl: QSslSocket errors/warnings

buckler

Hello,
My applications dump out the following:
qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback
qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_client_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_client_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_server_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_server_method
qt.network.ssl: QSslSocket: cannot resolve SSL_select_next_proto
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb
qt.network.ssl: QSslSocket: cannot resolve SSL_get0_next_proto_negotiated
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get0_next_proto_negotiated

It seems these are only warnings rather than actual errors, but I like to keep my warnings list down too rather than ignore them.

Help?

Thank you,
Andy

SGaist

Hi,

IIRC, this comes from the fact that the OpenSSL library loaded doesn't match the one used to build Qt. So you should either look to use the same library or rebuild the qtbase module to use your current version of OpenSSL.

buckler

Thank you, is there a link on how to do the rebuild on OsX?

SGaist

Basically:

mkdir build_qt
cd build_qt
/path/to/Qt/sources/configure -nomake tests -nomake examples
make -j9
sudo make install

You can also enable the new SecureTransport based backend which makes use of OS X cryptographic framework rather than OpenSSL.

buckler

Thank you. I have downloaded the source and followed the basic outline for the build - but I still have the errors :-(.

I am presently guessing that my application build may not yet be using the new Qt-built-from-source?

I use make for my build environment, and there are two lines I believe to be relevant:
set (CMAKE_PREFIX_PATH ~/Qt/5.5/clang_64/ )
set (QT_QTGUI_LIBRARY ~/build_qt/qtbase/lib/QtGui.framework)

Note, that I have edited the second one to reflect the new build location, hopefully correctly? I have not yet changed the first line, as I am unclear where to point it for the new material. The value indicated above is the value before the build-from-source.

So, the questions are: am I on the right path on my CMakeLists.txt change, and how should I complete it if so. Or - is there something else I should be doing?

Thank you,
Andy

Below is the full CMakeLists.txt:

cmake_minimum_required(VERSION 2.8.5 FATAL_ERROR)

project(ia)

add_definitions(-std=c++11)

option(WANT_DEBUG ON)

if (APPLE)
add_definitions(-Wno-macro-redefined -Wno-inconsistent-missing-override -Wno-potentially-evaluated-expression)
endif()

set (CMAKE_PREFIX_PATH ~/Qt/5.5/clang_64/ )
set (QT_QTGUI_LIBRARY ~/build_qt/qtbase/lib/QtGui.framework)

Tell CMake to run moc when necessary.

set(CMAKE_AUTOMOC ON)

As moc files are generated in the binary dir, tell CMake to always look for includes there.

set(CMAKE_INCLUDE_CURRENT_DIR ON)

Widgets finds its own dependencies (QtGui and QtCore).

find_package(Qt5Widgets REQUIRED)

The Qt5Widgets_INCLUDES also includes the include directories for dependencies QtCore and QtGui.

include_directories(${Qt5Widgets_INCLUDES})

We need add -DQT_WIDGETS_LIB when using QtWidgets in Qt 5.

add_definitions(${Qt5Widgets_DEFINITIONS})

Executables fail to build with Qt 5 in the default configuration without -fPIE. We add that here.

set(CMAKE_CXX_FLAGS "${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS}")

set(CPP cap_main.cpp cap.cpp workItem.cpp)
set(MOC )
set(UI cap.ui workItem.ui)
set(RCC cap.qrc)

qt5_wrap_cpp(MOC_GENERATED ${MOC})
qt5_wrap_ui(UI_GENERATED ${UI})
qt5_add_resources(RCC_RESOURCES ${RCC})

source_group("Form Files" FILES ${UI})
source_group("Resource Files" FILES ${RCC})
source_group("Generated Files" FILES ${MOC_GENERATED} ${UI_GENERATED} ${RCC_GENERATED})

include_directories($(CMAKE_CURRENT_BINARY_DIR) $(CMAKE_CURRENT_SOURCE_DIR))

qt5_add_resources(RESOURCE_ADDED ${RCC})
set_source_files_properties(${RESOURCE_ADDED} PROPERTIES GENERATED ON)

add_executable(my-app MACOSX_BUNDLE ${MOC_GENERATED} ${UI_GENERATED} ${RCC_GENERATED} ${CPP} main.cpp ${RESOURCE_ADDED})
target_link_libraries(my-app ${Qt5Widgets_LIBRARIES} )

set up the unit test targets

find_package(Qt5Test REQUIRED)

if (APPLE)
install(TARGETS my-app BUNDLE DESTINATION ~/bin/)
else (APPLE)
install(TARGETS my-app DESTINATION /usr/local/bin)
endif()

SGaist

You are telling cmake to look at your original Qt install not the one you compiled

buckler

I have now modified the first statement after groking the directory structure. The two lines that should point to the new are now as follows:

set (CMAKE_PREFIX_PATH ~/build_qt/qtbase/)
set (QT_QTGUI_LIBRARY ~/build_qt/qtbase/lib/QtGui.framework)

Yet, the same result, i.e., the errors persist. Either, is there more to do in order to point to the one I built, and/or, is there any other way to specifically look at the OpenSSL library specifically?

Andy

SGaist

Did you build Qt to use the Secure Transport backend ?

buckler

@SGaist I used the build instructions from your post;
mkdir build_qt
cd build_qt
/path/to/Qt/sources/configure -nomake tests -nomake examples
make -j9
sudo make install

(after downloading and extracting qt-everywhere-enterprise-src-5.5.1)

SGaist

You should have added -securetransport to your configure line for that.

buckler

In fact, even with this additional option I still was actually not completely using the manual build, and have been working, a result of the fact that the application is composed of multiple libraries each of which needs to link against the newly built Qt. So I finally got to that point, only to find out that my Qt build had in fact terminated early and I didn't even have the complete build! For some reason, it was stopping in qtquick (which I do not use), so I looked into how to avoid building qtquick and found out that there is a "-skip" option. This time, the build was taking a verrrrrrrrrrrrrry long time, and after 2+ hours I started to despair. The machine I am running on only has 2 cores, which I am sure contributes to the time. So I took a deeper look at what else I didn't need to try to reduce the build time, not knowing how long it might take. The configure that I finally came to was:
../qt-everywhere-enterprise-src-5.5.1/configure -nomake tests
-nomake examples -securetransport -skip qtdeclarative
-skip qtquickcontrols -skip qtwebchannel -skip qt3D -skip qtsensors
-skip qtserialport -skip qtwayland -skip qtandroidextras -skip qtx11extras

Now, this is currently building. I'm about an hour into it as I write this post.

Leading me to my next question: am I doing something wrong? Particularly with how long it is taking, I am worried that even this may fail in the end, and with so much time for the steps I hope you don't mind my seeking your feedback on whether I am on the right track and just need to be patient, or any wisdom you may impart would be deeply appreciated.

Many thanks,
Andy

SGaist

One thing than can speed things up: ensure you are doing only a release build.
Then, what modules do you need ? If only a few, you can start by building only qtbase and then use the qmake/make/make install combo for the other modules.

Don't forget to use -j3 when calling make, that will keep your two processors as occupied as possible.

buckler

Success! You are the master (but you know that already :-)!)

Thank you. Really.