[Interest] libeay32.dll - The Ordinal 4369 could not be located

Till Oliver Knoll till.oliver.knoll at gmail.com
Fri Jan 24 18:47:33 CET 2014


Am 24.01.2014 um 18:15 schrieb Thiago Macieira <thiago.macieira at intel.com>:

> On sexta-feira, 24 de janeiro de 2014 17:51:20, Till Oliver Knoll wrote:
>>> static void setLibraryPaths(const QStringList &);
>> 
>> Does that also affect where QWebkit searches for OpenSSL which is /not/ a Qt
>> plugin?
> 
> Yes, since QtWebKit uses QNetworkAccessManager, which uses QSslSocket.

... which on its turn - or whatever Qt component in the end - seems to search for an OpenSSL.dll in the PATH (according to the OP the program folders of "Tortoise" and "CMake" were scanned!). And PATH is clearly /not/ a standard "Qt Plugin Path".

So unless I am misunderstanding the obvious here it seems that "OpenSSL.dll" is loaded without respecting the "Qt library path" - which, I repeat, would also not make much sense (it would make sense to /include/ the Qt Plugin Path for that search, but unless the app provides its own OpenSSL.dll copy it is most likely found somewhere else, e.g. C:\Windows\System32).

Assuming that the search for OpenSSL is triggered by some Qt plugin I agree one could prevent that by tweaking the Qt plugin path, such that the *Qt plugin* itself would not be loaded in the first place (or compile Qt without support for SSL, as has been suggested).

But that's not what we are discussing here: the question is: where does the Qt plugin (or whatever Qt component) /itself/ search for "OpenSSL.dll"?

And the fact that locations like c:\Program Files\AnySuspiciousLocation are apparently scanned tells me that this search is not limited to the Qt Plugin Path...


Cheers,
  Oliver


More information about the Interest mailing list