[Interest] packaging a build

[maurice.kalinowski at nokia.com]

What you could do (in case you have time for a complete rebuild only for testing) is to change the mkspec to link the c-runtime into the application by changing the MD to MT flag.

However, that implies a full rebuild of Qt and your application just to verify that the source of problem is actually the runtime. Also I didn't check yet on how Qt5 behaves in that respect and if there are side-effects.

Maurice

________________________________
From: interest-bounces+maurice.kalinowski=nokia.com at qt-project.org [interest-bounces+maurice.kalinowski=nokia.com at qt-project.org] on behalf of ext Till Oliver Knoll [till.oliver.knoll at gmail.com]
Sent: Friday, September 07, 2012 10:14 AM
To: Qt Project
Subject: Re: [Interest] packaging a build

Am 06.09.2012 um 23:52 schrieb Morgan McKenzie <speedin_up at hotmail.com<mailto:speedin_up at hotmail.com>>:

Hi,

..., but on another Windows 7 64 bit computer, also with 2010 re-distributable installed, it does not work.

Sounds to me like you're in the Manifest Fiasko(tm)!

The safest and least painful way is to create an MSI Setup (Installer) which - within Visual Studio Professional/Enterprise - is only a click on some checkbox away from "bootstrapping" for you the proper "C/C++ runtime" at installation time and, if necessary, install it under c:\windows\system\WinSxS (or similar).

The downside of that approach is you a) need Visual Studio "Professional" or up (or whatever it is called these days) and b) last time I checked no other free Installer (e.g. InnoSetup) provides this option to "bootstrap" for the proper C++ runtime.

However the free MSI Installer WiX (-> google -> SourceForge) might be able to do that, but we're talking "XML setup files hacking" here - no fun!



The hardcore way is to place the necessary Visual Studio C++ runtime DLLs - I did not see them in your list! - manually either into the same place as the *.exe and mess around with the "Manifest" file. I can't remember the details, but I was involved in that mess once, too. You might find helpful information here:

  http://lists.qt.nokia.com/pipermail/qt-interest/2010-January/018187.html

Back in those days we eventually succeeded to ship our Qt application (built with Visual Studio 2003, later 2005) by simply providing the C++ runtime libraries in the same location as the *.exe - attention: don't confuse debug/release versions here either! - and messing around with the Manifest file (again, can't remember the details).

But in the end we still had one system - some Japanese Windows XP - which refused to start our application (it worked with the MSI Installer though)! So it turned out not to be 100% failsafe.


With MinGW and gcc on the other hand you don't have to mess around with all these "Side by Side" installations etc. All you need to do is use Dependency Walker and provide all those DLLs, typically in the same directory as the *.exe.


Qt plugins is yet another topic and has nothing to do with the compiler or the app not starting up (plugins are usually optional components, and in the worst case you simply miss some functionality - but the application usually starts up, unless it is some critical "platform abstraction plugin" or whatever)! Only there comes - optionally - the mentioned qt.conf file into play. Or you set the expected "Qt plugin base directory" programatically, e.g. relative to your *.exe's path. Or you simply place them where Qt looks for them anyway by default (e.g. /your/app/path/images - NOT ../plugins/images! -> chech Qt docs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120907/6d361795/attachment.html>