tags:

views:

189

answers:

3

Hello!

I have compiled my Qt application and now have the following question - now my built project requires QtCore4.dll and QtGui4.dll to be located at the same folder where the .exe file is. (I built my project using MSVS2008 with Qt addon)

Q:

Is there any way to combine my final application with these .dll files so that they make one large .exe-file? (I simply don't want to have another bunch of dll files with my release - app)

Thank you.

+7  A: 

You need to build and link to Qt statically.

Jerry Coffin
Note that statically linking the LGPL version of Qt is a grey area (not forgetting you need to build a static version of Qt first.)
Rob
@Rob: if you have doubts, you can contact either [email protected] or qt developers and ask them about static linking. Dynamic linking is safest licensing choice, though.
SigTerm
There's nothing "grey" about it: statically linking a LGPL lib binds you to release your source code.
Lucas
Jerry, plaese edit your links to use `/latest/` instead of `/4.2/`. Qt 4.2 is many years old now.
Lucas
@Lucas: done -- thank you.
Jerry Coffin
@Lucas: statically linking to an LGPL lib **doesn't** bind you to release your source code. It requires you to release your (compiled) object files so that they can be **re-linked** with a newer version of that LGPL lib.
Ken Bloom
+2  A: 

Of course you could statically link someway. But the point of using DLL should be to make program smaller (both on disk and in memory, if other apps are using Qt libs of course)... DLL such as those should be systemwide so that other apps needing them can use them. Basically you have to say to people wanting your program to work, to install the Qt framework.

Deploying the other way is explained here, read the part related to Static Linking.

ShinTakezou
Given current hard drive prices, and the difficulties that can (and do) arise due to conflicting DLL versions, this isn't really a good idea.
Jerry Coffin
ops it is the same link already given by Coffin, but from the introduction... Selecting your system (windows) brings you to the already given link but for v 4.2
ShinTakezou
@SinTakezou: Thanks for pointing out my mistake -- I've fixed the links.
Jerry Coffin
@Coffin, what a strange world; to me it's almost like saying a program should ship with the whole operating system suitable to run it... (and it is also why in some context the usage of a "thirdparty" non-lightweight framework is not my preferred choice). context of course decides what's better in the asker case (likely if it is for job, the statically-linked solution is better, but I wouldn't call it progress)
ShinTakezou
@ShinTakezou, I guess you have never tried to deploy an application built with visual studio C++ on windows, the runtimes for c++ do not sit on the system and have to be either statically linked in or distributed via an installer
Harald Scheirich
replicating codes for ever and ever...; I am glad I had not to deploy apps for Windows after all, and even if it would happen, I'l be always dissatisfied with the "totally static" solution. It seems preistoric.
ShinTakezou
+2  A: 

Bundle them into a self-extracting .exe (e.g. using 7zip) which extracts all files to a temporary directory, runs the program, then deletes the files after the program exits.

This will be easier, less time consuming and less legally constraining than statically linking Qt as previously suggested.

Intransigent Parsnip