Good afternoon, Firstly thank you everybody for taking the time to reply to me, I appreciate it very much. I have learnt quite a bit in the last few hours.
1, This issue was never highlighted because the application didn't explicitly require SSL, so it was never tested for as a feature. During development I had no means to realise this bug was waiting in the wings, I guess a best practice would be to run dependency walker and look for the loading of DLL's outside of the deployment folder and not Windows DLLs... 2, I made the mistake in saying that I did not have the OpenSSL DLL's on my computer, I have two sets in fact, the first in C:\Program Files\TortoiseHg and the second in C:\Program Files\CMake 2.8\bin\, running Dependency Walker and watching the application load shows it tries the TortoiseHg version and fails and then works with the CMake version. 3, I now understand that bundling OpenSSL DLL's has export/import implications: http://stackoverflow.com/questions/3516143/qt-ssl-support-missing 4, Qt 5.2.0 appears to be wanting a newer version number, ideally the 1.0 or newer: https://qt.gitorious.org/qt/qtbase/source/d4f6d6e5dc5c9e92bae80ce1895c7d7c6fdbd577:dist/changes-5.2.0 perhaps the my user has an even older version in their System32 folder, I am waiting to hear. 5, If I place an old version in the folder with the application 0.9.8y, it works, however I still need to find out which version the user has installed on their system to cause the pop-up message I have a version 1.0 that I can bundle next to the application and to use that. It would certainly be helpful to have the ability to toggle where QLibrary searches in a bid to remove potential security and usability issues, however that's clearly a philosophical point of view. Regards Phil On 24 January 2014 13:41, Scott Aron Bloom <[email protected]> wrote: > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf > Of Phil Hannent > Sent: Friday, January 24, 2014 4:21 AM > To: interest > Subject: Re: [Interest] libeay32.dll - The Ordinal 4369 could not be located > > On 24 January 2014 11:43, Richard Moore <[email protected]> wrote: >> On 24 January 2014 11:07, Phil Hannent <[email protected]> wrote: >>> On 24 January 2014 10:57, Soroush Rabiei <[email protected]> wrote: >>>> libeay32.dll belongs to OpenSSL library. I think you have to find >>>> which DLL your code links against and copy it beside your >>>> application. That will fix all (except legal possible issues). You can use >>>> dependency walk to find it. >>> >>> I am aware this is an OpenSSL library, however I don't actually >>> depend on it. My application runs fine on development machines and >>> clean test machines. The Qt 5.2.0 installation does not contain that >>> DLL so I assume its compiled into a DLL like QtWebKit. >> >> Qt dynamically loads openssl (using QLibrary) when you try to use SSL >> for the first time, so just because your application isn't linking to >> it directly doesn't mean you don't depend on it. Qt does not have >> openssl 'compiled into it' unless you build your own copy of Qt using >> the -openssl-linked option. >> >>> >>> The problem is that when the file exists Qt is picking it up, when it >>> doesn't exist its using its own internal one. How can I get it to >>> always use the internal one? >> >> There is no internal one. > Great, thank you for the clarification. > > However could you explain how QtWebkit is able to view https pages when the > libeasy32.dll is not in my path or next to the application? > -------------------- > > Most likely, some application, installed it into system32.. or some where > else in the path > > When you run depends.. where does it pick it up from? > > Scott _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
