Important: Please read the Qt Code of Conduct -

[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 ( 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


  • Lifetime Qt Champion


    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.


  • Lifetime Qt Champion

    It might if you give the static libssl

Log in to reply