[Solved] Mac Qt 4.8.4 and libssl 1.0.1e ... qt loads wrong version
My application uses Qt 4.8.4 (currently, we are trying to finish a port to 5.2) and we link to openssl 1.0.1e. When we built Qt, openssl was enabled but it appears that Qt uses dlopen to load the ssl library. I don't see it in the dependencies when I run otool -L on the qt binaries so this is not an install_name path issue. What appears to happen is that at runtime, qt uses libssl 0.9.8 because that is what comes with OSX (it is in /usr/lib) while my app uses 1.0.1e when we call the openssl apis. This results in a crash (BAD_MEMORY_ACCESS) because it looks like the X509_Name structure changes and I can see that some of the members are ... trash. Given this assumption, I set the DYLD_LIBRARY_PATH in my apps Info.plist (pointed to my apps Frameworks directory which contains the 1.0.1e lib) and ... no crash, which makes me feel pretty confident about my deductions. I would prefer to not do such a heavy handed. I found this post from a while ago (http://www.qtcentre.org/threads/52152-Use-openssl-1-0-0-with-Qt-4-8-3-on-Mac) but there was no useful answer. I can't force my customers to upgrade to 1.0.1e so I plan on shipping it.
Can someone tell me how I might solve this?
Using static linking would bloat qt binary sizes (and I am shipping the module so would be .... silly) so that is no good.
Can someone tell me if there is a way to get Qt link to 1.0.1e without using dlopen such that I could use install_name_tool to change the path
Can someone give me another idea?
Surely people want to link with newer versions of opensll than what ships with the OS
IIRC you can use -openssl-linked when building Qt which should do what you want
Hope it helps
Ahhh ... I see my confusion. I thought "linked" was doing static linking. "Linked" is simply "linking" to the openssl library instead of using dlopen. I will give that a shot.
It might if you give the static libssl