[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 OSThanks
-
Hi,
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.
Thanks
-
It might if you give the static libssl
