Using Qt network functions with different OpenSSL versions

Question

I am interested in using Qt's Network functions included with the network module in some applications that use my own compiled OpenSSL. I would like to use this application in osx, ios, and android. What is the proper way to make this happen? With the Qt5 binary install from the qt website, I was able to deploy to both Android and and OSX, but I could not deploy to iOS. To change the iOS kit, I created an environment variable OPENSSL_LIBS and set that to my iOS openssl compile, but I was unable to get the compile to link to that version (it kept linking to my system installed OpenSSL).

Someone in the forums said I needed to compile Qt with the openssl-linked configure option, but I haven't been able to get that working either. Can someone instruct on how to proceed on either of these things: Linking to different OpenSSL versions with the binary Qt5 install, or compiling Qt5 from source linked to a different version of OpenSSL.

Answer 1

I would like to use this application in osx, ios, and android. What is the proper way to make this happen?

Mac OS X and iOS are the problem children. The problem with Apple tools are: 1) the linker does not honor things like rpath and -Bstatic; and 2) the link editor does not honor rpath and LD_PRELOAD.

For (1), the linker will silently drop rpath. Additionally, -Bstatic is simply ignored. So you will always link to a shared object or dylib if available, and its probably going to be the wrong one.

When linking against OpenSSL on Mac OS X, you're more than likely going to get one of the system dylibs:

$ find /usr/ -iname libssl*
/usr//lib/libssl.0.9.7.dylib
/usr//lib/libssl.0.9.8.dylib
/usr//lib/libssl.dylib

For (2), the link editor does not have a rpath and does not honor LD_PRELOAD, so you will again link against the system libs.

The symptom is usually obscure failures because the program was compiled against, for example, OpenSSL 1.0.1 while it was linked against 0.9.8 at runtime. The data structures are different on occasion, so you get obscure crashes that make no sense. Here's a perfect example of what I'm talking about: Coredump when compiling python with a custom openssl version.

The way to fix it is to omit -L, -lssl and -lcrypto. Instead, you should specify the full path to an archive. For example, on Mac OS X, I have to specify /usr/local/ssl/lib/libssl.a and /usr/local/ssl/lib/libcrypto.a.

Static archives are just a collection of *.o files. You should try to specify the the archive path in "Additional Object Files". If you can't, then try and add them ass additional libraries. I know how to do it in Makefile projects, Eclipse projects and Xcode projects, but I don't know how to do it under QtCreator. But Laszlo Papp tells you how to do it at Adding object (.o) files to qtcreator project.

Below is a similar example under Xcode, where I'm linking against Crypto++ rather than OpenSSL. However, notice I specified the full path to the archive. (This was an Xcode project, and I got errors on the devices because it could not load the Crypto++ shared object).

You will also have to ensure other OpenSSL dependent libraries are compiled and linked against your version of OpenSSL. I usually take the same approach - compile the dependent library against the static archive (even if it means code bloat). For example, I have a libevent project that links against my static version of OpenSSL; and my project links against my static version of OpenSSL. It sucks, but its what you have to do until Apple fixes their broken linkers.

Linux is much better behaved, and you can use an rpath or LD_PRELOAD. However, since you are jumping through hoops for Apple, you might as well do the same thing everywhere.

Whatever you do, DO NOT use -L, -lssl and -lcrypto on Apple platforms. Xcode will never get it right, even on iOS where the only libraries you are suppose to use are static archives. Apparently the Xcode developers did not get the memo, and Apple QA did not test things (what's new).