Error deploying QT5.4.1 in windows x86



  • I am trying to deploy a QT5.4.1 appplication on Windows 7 - x86.

    As always, everything is working fine on my machine, but not in the end user's machine.

    When I try to run the app, it gives me the following error:

    "The application failed to start because it could not find or load QTplatform plugin windows"

    After searching on the internet, most solutions say that I need to add a platforms folders containing some dlls (qminimal, qoffscreen, etc) to the deployment package. I tried that with no success.

    The funny thing is that I copied QT installation folder to the end user machine and deleted everything except this folder (C:\Qt\Qt5.4.1\5.4\msvc2012_opengl\plugins\platforms) and it works fine.

    So, somehow my app is looking for the platforms folders in QT installation folder instead of the deployment package folder.

    Does anyone know how to solve it?



  • Hi, the reason why C:\Qt\Qt5.4.1\5.4\msvc2012_opengl\plugins\platforms always works, it that this path is written into the Qt5Core.dll when you installed Qt. But that's only one way for Qt to locate the platform plugin DLL, it should work also for you to put a folder named platforms (containing qwindows.dll) together with your .exe file.
    A 3rd alternative is to create a qt.conf file, and place it together with your .exe file, in it put two lines:

    [Paths]
    Plugins=path to your platforms folder
    

    Note: use forward slashes and also, the path should not specify the platforms folder itself, for example if your qwindows.dll file is in C:\MyDeployment\platforms qt.conf should be:

    [Paths]
    Plugins=C:/MyDeployment
    


  • Hi, thank you for your answer... I figured out what is wrong, but I need some help to solve it.

    My project output is a DLL that has a GUI made in QT.

    Another program calls this DLL and during DLL_PROCESS_ATTACH a QT GUI is created.

    That´s why the QCoreApplication::applicationDirPath() is not the deployment directory where the DLL is located, but the directory where the external program *.exe is running. I think QT is looking for the qt.conf file in this *.exe location

    It is not possible to place the plugins folder or qt.conf in the *.exe directory, due to several other reasons.

    What do you recommend in this situation? Is it possible to change applicationDirPath to the location where DLL is located?



  • Yeah, changing the path in the code instead is a good idea, when loading the platform plugins Qt traverses the QCoreApplication::libraryPaths, to change it either append to it with QCoreApplication::addLibraryPath or in your case, would be easiest just to reset it with QCoreApplication::setLibraryPaths().
    Note that this call has to be made before constructing QCoreApplication, because that's when Qt loads the plugin(s).

    Edit: one other alternative is to binary edit your Qt5Core.dll (if you know the exact location beforehand, where your .dll is going to be deployed to).



  • I would like to reopen this issue.
    Everything was working fine in 5.4.1, but due to other reasons I had to downgrade QT version to 5.2.1.

    By doing so, a whole new set of problems occurred, including "failed to load windows platform dll".

    Here is the code that used to work in 5.4.1:

    	QApplication *app = NULL;
    
    	BOOL APIENTRY DllMain( HMODULE hModule,
    						  DWORD  ul_reason_for_call,
    						  LPVOID lpReserved
    						  )
    	{
    		switch (ul_reason_for_call)
    		{
    			case DLL_PROCESS_ATTACH:
    				{
    					std::string runningFolder =  "C:\path\to\plugin\folder";
    					
    					QStringList paths;	
    					paths.append(runningFolder.c_str());
    					QCoreApplication::setLibraryPaths(paths); 
    
    					app = static_cast <QApplication *> (QApplication::instance());
    					if ( app == NULL )
    					{
    						int argc = 0;
    						app = new QApplication( argc, NULL );	
    					} 
    				}
    				break;
    			case DLL_PROCESS_DETACH:
    				if ( app != NULL )
    				{
    					delete app;
    				}
    
    				break;
    			}
    		return TRUE;
    	}
    

    Why it is not working anymore in 5.2.1? Any clues?

    EDIT: The running .exe (which calls this dll), was also developed in QT (if a different version). Not sure if it is a relevant information



  • Hi, if the .exe use another version of Qt; alas, that means your .DLL and the .exe will both load the plugin DLL qwindows.dll, but only one will succeed and the other one will casue that "failed to load..' message, because on Windows, an .exe file cannot load one more than one .dll with the same name (regardless of the path).

    EDIT again: just realized, because Qt only cares for the name of the folder (platforms) and loads what'sever in there, you could get away with this by renaming your 5.2.1 copy of qwindows.dll to say grapefruit.dll.
    Qt will still load it fine and this might help you get around that double dll syndrome. However, you might instead stumble on the normal Qt dlls like qt5core.dll :-(

    EDIT: there is a trick/workaround for the double DLL syndrome, taken from the .NET world, by using an assembly and manifest



  • hskoglund,

    I reverted the QT version back to 5.4.2 and the problem no longer exists.
    (ps: i found versions x64 and x86 of mscv2012 in here)
    I figured out that using a different QT version is easier than actually solving the problem.

    I don't know why, but 5.2.1 and 5.4.2 versions ARE quite different regading this issue.

    About the DLLs, I changed the name of windows.dll to orangeJuice.dll just to be sure I would have no problems, althought it worked fine with its original name.

    Also, I cant say for sure (since I am a newbie), but the .exe must have some kind of custom mechanism in order to load two versions of QT in different application context. The .exe program is a well know and widely distributed software with hundreds of engineers, so they must implemented a workaround.

    thank you for your support, It helped a lot.
    cheers



  • Good to hear.

    Just want to add, most of the big wheel programs that are built on Qt, usually are linked/built statically, which means no dlls will conflict for a scenario like yours.

    I'm guessing, but if you're adding a plugin to perhaps VLC?, then all of their Qt stuff (including their own qwindows.dll and qt.conf etc.) are linked together into one humongous 12 MB file (C:\Program Files (x86)\VideoLAN\VLC\plugins\gui\libqt4_plugin.dll) so the double dll syndrome never occurs :-)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.