Crash on startup because wrong Qt libs are loaded (Win 7)

Hmm, I suspect very few people are going to have Visual Studio 2010 built Qt libraries sitting in their path on their Church presentation laptops!

I don't have Visual Studio 2010, and have no plans to build Qt myself. We use PyInstaller to package up the exe, but I'm not sure I'd even know where to begin to look at how to resolve this problem. It would likely take a long time to investigate and that time might be better used elsewhere, and even then there is no guarantee we could fix it.
However please feel free to investigate the problem yourself, since it looks like you are in the best position to do so! :)

I think to resolve this it would be necessary change Pyinstaller bootloader to somehow manipulate its PATH environment variable and perhaps some .manifest files. Technically, it is a change in the C code.

matysek, perhaps PyInstaller could set it's temporary directory (in one file mode) or the app directory (in it's one dir mode) as the first directory in PATH when it runs?

Now I installed 1.9.6 on another computer (with Vista 32-bit) and got another similar error before the Qt-related one:
Before even the splash screen was shown, a popup came up:
"The procedure entry point "libiconv_set_relocation_prefix" wasn't found in the DLL "iconv.dll." (translated from German)
When I click ok, the splash screen is shown and after a few seconds the app crashes as described in the first post.

I've found an iconv.dll in "C:\ruby\bin", which is also in my PATH, so it's basically the same problem.

I remember I was facing a similar issue some time ago when trying use pyinstaller for my PyQt app. But I can't remember how I solved it.

But I think it is not an pyinstaller issue because on Windows the folder with .exe file is first searched for dlls and after that in PATH.

So basically, this error should mean that some dlls are mising in the build.

In the case of iconv.dll it means that this file is not present in the folder where is the OpenLP.exe.

Hmm....I just removed all Qt libs and iconv.dll-copies from my PATH by temporarily renaming their folders to test this (there were a few more) - now I get the message that iconv.dll couldn't be found and OpenLP starts normally when I click ok. The iconv.dll really misses in the main folder, but it's in OpenLP/enchant. But the Qt DLLs are obviously all there and loaded correctly...

When looking closer at the list of files in the openlp build for windows, iconv.dll file is present in the 'enchant' folder. The 'enchant' folder seems like not packaged directly by pyinstaller.

I think the way of packaging enchant in windows build is the cause of this bug.

I've had another look at the call stack and I may have found the cause of the Qt problem: qgenericbearer4.dll is not part of the OpenLP build and therefore loaded from "C:\Qt\4.7.1\plugins\bearer\" (my Visual Studio 2010 build).
I don't really understand how, since it's not actually in the PATH, but the call stack shows that QtCore4.dll uses msvcr90.dll (and is therefore likely to be the one from the OpenLP folder) and only qgenericbearer4.dll calls into msvcr100.dll. Here's the full stack: http://pastebin.com/4csYfRc8

The enchant issue could be resolved in pyinstaller by implementing a hook for it:
http://www.pyinstaller.org/ticket/12

or by better way of packaging it with openlp.

I don't know what all is installed on the above machines, but I don't even have qgenericbearer4.dll anywhere on mine and OpenLP runs fine. From what I can find, this dll appears in a "Windows Fedora" package of QT. I do not believe this Dll is required in a 'normal' install of WIndows.

I do have iconv.dll (located in the Openlp install directory - C:\Program Files (x86)\OpenLP\enchant ) but I don't see it in the OpenLP process list when the program is running. This may be due to the language set I am using (English) and the use of of the dll is not required.

The entire Enchant package (less python scripts) is specifically included in the Windows build. I am building using pyenchant-1.6.5.win32

OpenLP doesn't seem to need qgenericbearer4.dll to run, but if it is found, it is loaded. The Qt Bearer plugin isn't part of PyQt, so packaging with OpenLP wouldn't be easy (Could be added manually of course...). Perhaps the PATH environment variable could be deleted for the OpenLP process on startup (-> os.environ['PATH'] = ''). That should prevent any incompatible external DLLs from being loaded. My case may be special, but there are Qt applications that write their bin-directory into the PATH on installation (e.g. MiKTeX), so similar problems might occur.

With iconv.dll it's similar, but there the obvious fix would be to put it in the main OpenLP folder instead of OpenLP/echant. I also noticed that I don't get a popup on my Win 7 machine, when iconv.dll is missing (but it's also loaded when present in the main OpenLP folder or somewhere in the PATH).

I'm not sure if delete the PATH at startup will help.

Deleting it could help to some extent (modules will use dll from openlp dir], but PATH also contain dir with system libraries - this would break modules depending on dll from C:\windows\system32, etc.

Karan, can you test if deleting PATH will help?

Karan, you mentioned that Bearer is a qt plugin. There is another thing you could try.

Could you please check if on your win 7 is set the environment variable QT_PLUGIN__PATH?
If it is set then openlp on your system is probably trying to load qt plugins from those folders.

If so, openlp should probably unset this variable at startup.

Could you please also try to unset this variable and run openlp if it will work on your machine?

For list of available qt variables see:
http://qtunderground.org/wiki/Qt_Environment_Variables

> PATH also contain dir with system libraries - this would break modules depending on dll from C:\windows\system32, etc.
That's not quite right, system directories are searched before the path (http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.80).aspx), so that shouldn't be a problem.

> Karan, can you test if deleting PATH will help?
When I start OpenLP from the source, the problem doesn't occur, so I guess I'd have to make an .exe with PyInstaller to really test it. I tried removing PATH and all Qt environment variables in a command shell and then starting OpenLP from that shell, but it didn't work (still crashing), although Process Explorer showed that the variables really didn't exist for the OpenLP process.

> Could you please check if on your win 7 is set the environment variable QT_PLUGIN__PATH?
No, my only Qt variables are QTDIR, QT4DIR, QTDIR_DEBUG.

Thanks Karan.

What do I need to install to have similar environment as you have?

>> PATH also contain dir with system libraries - this would break modules depending on dll from C:\windows\system32, etc.
> That's not quite right, system directories are searched before the path (http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.80).aspx), so that shouldn't be a problem.

But that information is for situation when starting a new process. With openlp the situation is different. DLLs for python modules are loaded dynamically at runtime (when process is already started).

We need to try that and make sure how it works.

I would like to get an evironment similar to yours.

> I would like to get an evironment similar to yours.
My environment takes quite a while to set up, maybe you can get away with just the problematic DLLs: http://dl.dropbox.com/u/5464702/OpenLP_incompatible_DLLs.zip
It's the iconv.dll from my ruby installation and qgenericbearer4.dll within the Qt directory structure. I have the environment variables QT4DIR and QTDIR pointing to Qt/4.7.1, and Qt/4.7.1/bin in the PATH.
But I'm not sure anymore if the environment variables are even used - OpenLP even crashes when I remove all references to my Qt build (and reboot). And I found all plugin paths also in the registry (HKEY_USERS\S-1-5-21-2378048838-1455849807-2857485230-1000\Software\Trolltech\OrganizationDefaults\Qt Factory Cache 4.7).

(My full environment is: Ruby 1.8.6 (bin directory in the PATH), Qt 4.7 for VS2008 (http://qt.nokia.com/downloads/windows-cpp-vs2008), configured for Visual Studio 2010 (witht configure.exe in the main Qt folder, something like configure -platform win32-msvc2010 I think), then compiled by executing 'qmake', then 'nmake' in the Visual Studio 2010 Command Prompt. Perhaps it would be enough to just install it and replace qgenericbearer4.dll with my one....)

I also found that the Qt search paths can be overridden with a qt.conf file: http://doc.qt.nokia.com/latest/qt-conf.html
I tried putting one into the OpenLP folder with "[Paths]\nPlugins = qt4_plugins", but nothing changed.

Karan, could you please try setting in console QT_DEBUG_PLUGINS to non-zero value and try to start OpenLP?
Maybe this could give us some useful debug info.

Other resources:
http://doc.qt.nokia.com/latest/deployment-plugins.html
http://doc.qt.nokia.com/latest/qcoreapplication.html#setLibraryPaths

Could you also please try the following code in your python and let me know its output? Thanks in advance.
(I assume you have installed python environment with PyQt4)

import sip
sip.setapi('QString', 2)
from PyQt4 import QtCore
QtCore.QCoreApplication.libraryPaths()

Hi Matysek,

I set QT_DEBUG_PLUGINS, but I don't know where I'd find the debug info...

I also tried your code snippet - the output was an empty list. Though I suspect something different might happen when the installed version is started, since OpenLP never crashes when I start it with Python (directly from trunk). Is the PyInstaller-Windows-Guide on the wiki still up-to-date? Maybe I'll making my own build with some PATH/libraryPath-testcode when I find the time...

the debug info should be printed on console - well, I realized that the build is not a console app.

What guide you mean? Something on openlp wiki?

This issue is fixed in pyinstaller svn: http://www.pyinstaller.org/ticket/375

Invalid, as this was not a bug in OpenLP.