Skip to content
  • 0 Votes
    2 Posts
    748 Views
    SGaistS

    Hi and welcome to devnet,

    Are you sure you library can be found ?

    What version of Qt are you using ?
    On what platform ?

  • 0 Votes
    3 Posts
    3k Views
    D

    I figured out my problem... I forgot to include the widget in the .lib.pro file...

  • 0 Votes
    5 Posts
    2k Views
    D

    @ThirdStrand said in Force system QT libraries to use openssl libraries shipped with the application:

    @JKSH One would do this to ensure that the libraries used are the proper libraries which are expected in the program. In much the same way as we deploy the appropriate versions of Qt libraries, why not use a KNOWN library when deploying the libssl and libcrypto libraries?

    If you want to use known libraries in your app without the possibility of user interference you should probably use static libraries and not dynamic. Because even if the other libraries are not in the system path there is always at least one user who might want to exchange your library with another one - perhaps optimized for his computer ;) Had this a couple of times on windows with DLLs and a lot with java apps where users just replaced „outdated“ libraries.

    This has become the bane of my existence, and I am here in search of WHY it will work when it is in QtCreator and NOT work when deployed with the EXACT same loaded library files.

    I didn‘t see your used OS but I could imagine that Qt Creator uses LD_PRELOAD mechanism to ensure that the specific libs are loaded first. This at least should work an Linux, I don‘t know any trick for that on windows. AFAIK macOS offers a similar mechanism to Linux.

    By way of venting, this old question gets some new life. I have seen many "answers" which usually consist of "The user should install....", which anyone who has ever actually deployed retail software knows is an absolute NIGHTMARE.

    Witness ProtonVPN! This commercial application is deployed with a specific (v1.1.1j) set of OpenSSL libraries. Why? Because it is developed with that version and is tested with that version. Why opt to allow the end user to change the libraries and break your application at will? That's just self-defeating.

    Still this doesn‘t prevent the user from changing the libs themselves. And given the fact that the build environment doesn‘t often change it might very well be that they will be shipping an „outdated“ version - because the app was developed with it - and tested. When I worked on Air Traffic Control Software we almost never updated our libraries - because they were „tested“.

    As I said earlier: If you want to prevent user modification use static linking. This way the size of your deployed app will also shrink.
    But be sure to check possible licensing restrictions.