3

Well, I've spent a day looking for solution and have read everything but I am not able to deploy my Qt application, so I decided to ask.

I'm using Qt 5.2.1 via the Visual Studio Add-In in VS 2013 Ultimate, the qt version is msvcr2012. I have the x86 version of Qt 5.2 (now the 3rd from the bottom at Qt Downloads page).

I'm targeting Win7 32-bit.

My OS is Windows7 64-bit, I'm building the app for win32, release /o2 (max speed) optimalization, /MD (dynamic C runtime), with libraries linked:

qtmain.lib
Qt5Core.lib
Qt5Gui.lib
Qt5Widgets.lib
Qt5PlatformSupport.lib //this one is added by me, the others are automatically set with the Qt-AddIn template.

I build it, and to the release folder I put the followings:

EDIT: because of the version of my compiler, I also distribute the vs2012 dll.s as you see.

enter image description here

.../release                                            /plugins        /platforms

I've set the addittional library path with (just for the 100% chance of finding them):

void registerPluginsDir(QDir& exeDir)
{
QString pluginsRelPath = "plugins";
QString platformsRelPath = "platforms";
QString pluginsPath = exeDir.absoluteFilePath(pluginsRelPath);
QString platformsPath = QDir(pluginsPath).absoluteFilePath(platformsRelPath);
QStringList pathes = QCoreApplication::libraryPaths();
pathes << pluginsPath;
pathes << platformsPath;
QCoreApplication::setLibraryPaths(pathes);

for (auto i : pathes)
    qDebug() << i << "\n";
};

int main(int argc, char *argv[])
{
    QString exePath = QString::fromUtf8(argv[0]);
    QFileInfo exeInfo(exePath);
    QDir exeDir(exeInfo.absolutePath());
    registerPluginsDir(exeDir);

    QApplication a(argc, argv);
    KeyGenerator w;
    w.show();
    return a.exec();
};

The pathes are correct. With the debugger I saw they were loaded from my app folder, not from the Qt main folder.

With depends.exe I checked everything. I only get 2 warnings, no errors: 

Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

I've copied the .dll-s according to the .dll-s loaded when debugged the app in Visual Studio. The only difference between depends.exe and the debug, that in VS system dll-s were loaded from SysWOW64, not system32.

With all these on my (developer) pc it runs withouth any error, but on the test (Win7 32-bit running on Microsoft Virtual PC) pc I get the 'infamous' error:

Failed to load platform plugin “windows”. Available platforms are:
(and here there are the full pathes to the .dll-s, 
eg: D:\cproj\keygen\win32\Release\plugins\platforms\qwindows.dll, so it must have found them.

I followed this too: http://qt-project.org/wiki/Deploy_an_Application_on_Windows.
Renamed the Qt-dir, the console only output the release folder as library inputs (not the Qt-folders like my first test). It loaded the dll-s from the app folders, launched well. However, on my virtual PC, or on my brother's pac (Win7 32bit) it gives me the error.ˇA picture about this:

enter image description here

How to run it on 32-bit machine? I tried it with every build, release-win32, debug-win32, none of them works. I can't test it on more machines, on XP it can't even load the C-runtime, but that's not a target platform.

For more info please comment.

EDIT: Dependency walker on target pc shows the same as on dev pc. It still finds the plugins, but can't load.

David Szalai
  • 2,363
  • 28
  • 47

2 Answers2

3

I don't know why you bother with setting of the paths etc. The Qt wiki article that you link shows that you don't have a plugins folder, but everything from that folder should go into your executable's folder.

deployment screenshot

The advice they give is very simple:

  1. Every .dll from Qt's bin directory needs to be copied to your executable's folder.

  2. Everything (files and folders) from Qt's plugins and qml folders needs to be copied to your executable's folder.

You can then cut it down to modules that you don't use. Works for me, just fine.

It is also incorrect to say that "I have to add the .dll-s to the release build because I'm not using the commercial version.". If you follow my advice, you can easily build statically-linked executables with Qt 5 and MSVC 2012, I'm even giving details on how to target Windows XP with all that. And you can do it just fine under terms of LGPL, you just need to let your users relink your project (that doesn't imply giving out C++ sources!).

Community
  • 1
  • 1
Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
  • 1
    It's a terrible idea to deploy static linked anything. – user3427419 Mar 19 '14 at 05:45
  • Not working, same as the previous. It finds everything in this folder when I run on my PC (win7 x64), but on virtual machine or another Win7 x86 it finds them there too just can't load. – David Szalai Mar 19 '14 at 16:27
  • @user3427419 Why? It allows a lot of global optimizations, and results in a single executable that is, in aggregate, smaller than the dynamically-linked one with all the dependencies next to it. On Windows it's pretty much a must, unless you like bloated installers. It's very unlikely that anyone will be running some other binary-compatible version of Qt so that the dlls would be shared. On Unix systems with package managers it's a whole different story, of course - except when you want to forestall some reverse engineering; then it's still a good idea to statically link. – Kuba hasn't forgotten Monica Mar 19 '14 at 17:04
  • I finally solved. Check my answer, and thanks for yours! – David Szalai Mar 19 '14 at 17:06
  • Regarding static linking, first and foremost is _security_. It is not easy for users to patch a critical problem in 3rd party code, like Qt or webkit or openssl or some other library (like MSVC runtime) if you static link. Heck, worse, they will most likely not even be able to know that a problem exists! As for performance, that is not a valid reason not to use dynamically link for a long time now. Regarding size, a Qt app with webkit, runtime redist, openssl is under 10MB installer. Quibbling over a few MB of disk space weighing against security implications mentioned above is not worth it. – user3427419 Mar 19 '14 at 22:38
0

The problem was not with the plug-ins, but it also requested the VS2010 redists.
After I tried everything I've found it in the Qt folder, and tried running my app with installing it. Now it runs on the Virtual PC too, however, it was not listed (or I oversaw this) in the dependencies. It only listed 2012 and 2013 versions.

David Szalai
  • 2,363
  • 28
  • 47
  • You seem to be mixing things up horribly. I've now noted that in the question you claim "Visual Studio Add-In in VS 2013 Ultimate, the qt version is msvcr2012". You **absolutely, positively can't mix a qt built for one msvc, with another msvc**. If you're using prebuilt Qt for MSVC2012, it won't work correctly with anything **but** MSVC2012. The fact that you seem to need MSVC2010 redistributables to run a Qt for msvc2012 is telling that something is horribly wrong. You should only need the redistributable for the compiler used to compile Qt, and you should use same compiler to build your app! – Kuba hasn't forgotten Monica Mar 19 '14 at 17:15
  • If you want to use msvc2013, you need to **compile Qt** first since there's no prebuilt Qt for msvc2013. Only then build your application using it. It will work fine, and you don'e need any VC redistributables besides the one for msvc2013. – Kuba hasn't forgotten Monica Mar 19 '14 at 17:18
  • I can use it if I send the Qt version of C runtime too, the only thing i can't understand is the purpose of the 2010 package, since I downloaded the 2012 version. Now deeply examining the dependency walker. But yeah, it's a good idea to recompile it. – David Szalai Mar 19 '14 at 17:22
  • "I can use it if I send the Qt version of C runtime too" No, you can't. Things will be subtly broken, and the fact that it doesn't deploy properly is merely the tip of the iceberg. If you've downloaded prebuilt Qt for MSVC2012, **you must use it with MSVC2012**. If you want to use Qt with MSVC2013, **you must build it yourself** since at the moment there's no prebuilt binary for MSVC2013. It's not just a good idea. It won't work otherwise. I mean, come on, you've **shown** that it doesn't work, there's no point in arguing it. – Kuba hasn't forgotten Monica Mar 19 '14 at 17:30