Am 24.01.2014 um 18:15 schrieb Thiago Macieira <[email protected]>:
> 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 _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
