[solved] Questions on deployment

[mzimmers]

Hi -

I'm at a point where I really need to be able to easily distribute apps I'm building with Creator to users. I tried asking about this a month or so go, but the thread didn't really go where I needed, so I'm going to try again. Hopefully I can ask better questions this time.

Ultimately it would be nice to be able to deliver programs for Linux, MacOS and Windows, but for now, I'm content to just concentrate on Windows. I read this page:

"Windows Deployment":http://qt-project.org/doc/qt-4.8/deployment-windows.html

And I have a few questions. (I want to proceed very carefully, so I don't "break" anything that's currently working.)

the page talks about a "configure" command in my Qt path. The only one I found is in QtSDK\Desktop\Qt\4.8.0\mingw -- is this the right one to use?

the page talks about "building" Qt statically. Qt is already built on my system; does this mean I'll need to re-build it? Will I need to download source code first?

is there an option on the configure command to tell me how my current Qt is built? I looked through the help but nothing jumped out at me.

what do I need to do to ensure that by rebuilding Qt, I don't "break" something in how it's currently working?

Also, if anyone has any words of wisdom on whether I should go with static linking, I'd love to hear it.

As an aside, the current app I'm building doesn't use the Qt GUI libraries, but...I expect that future apps will, so this is a very worthwhile undertaking for me.

Thanks.

[koahnig]

[quote author="mzimmers" date="1334014677"]

the page talks about "building" Qt statically. Qt is already built on my system; does this mean I'll need to re-build it? Will I need to download source code first?

[/quote]

Building Qt statically is certainly one option, but there is the "licensing. ":http://qt.nokia.com/products/licensing

[andre]

I found that distributing on windows really isn't that hard with dynamic libraries. For the main Qt DLL's, you only need to put them next to the executable. The plugins go into plugin directories under that.

[mzimmers]

Andre -

How do I go about determining which Qt DLLs an application needs? Currently, when I use a CLI to try to start an app, it just returns without any error messages (and without starting the app, too.)

And, if I'm currently not using any Qt features, am I correct in assuming that I'm not using any plugins? Or, does the directory need to be there anyway?

[andre]

There are tools for that. Roughly, each Qt module you use (have enabled in your .pro file) has a corresponding dll that you need to distribute. Next to that, you also need to distribute dll's that depend on your toolchain. With MinGw, that would be mingwm10.dll and libgcc_s_dw2-1.dll.

The "Dependency Walker":http://www.dependencywalker.com/ tool will tell you all you need to know about the dependencies of your application.

[mzimmers]

Interesting. According to Dependency Walker, there are five dependencies:

• c:\windows\system32\KERNEL32.DLL
• c:\qtsdk\mingw\bin\MINGWM10.DLL
• c:\windows\system32\MSVCRT.DLL
• c:\windows\system32\MSVCRT.DLL
• c:\qtsdk\mingw\bin\LIBGCC_S_DW2-1.DLL

All but the fourth one are expandable in DW to reveal other DLLs, but I assume that's not a problem.

So, did I understand you correctly that now I need to make copies of these and place them in the execution directory? Is any change to the build process necessary?

And, do I really copy the kernel32.dll? Or should I expect that the user will have that on his system?

Thanks...I finally feel like I'm getting somewhere.

[koahnig]

You may want to try it. It will tell you the missing dlls. A customer is certainly not the best place to test this ;) That is only done with operation systems :)

The system32 dlls are depending on your operation system installed. AFAIK you do not need those.

But you do not have Qt dlls in your list ! ? !

[goetz]

With MinGW you need:

• libgcc_s_dw2-1.dll
• libgomp-1.dll
• libpthread-2.dll
• libstdc++-6.dll

Everything else that dependency walker reports is usually installed in the system of a windows box.

And the Qt libs:

• QtCore4.dll
• QtGui4.dll

And later on, whatever you have as additional Qt modules (network, xml, webkit...) as well as the plugins (iconengines, imageformats, sqldrivers...). But that's pretty much the same on every platform.

With MinGW you're done with putting all those DLLs besides your executable (exepct the plugins, these go into subdirs as usual), you do not need to install the C/C++ runtimes in a system directory as with MSVC's vcredist.exe.

[mzimmers]

Hi, Volker. Good to hear from you. So, why is it that some of the libraries you mention aren't shown by Dependency Walker? Or, maybe I just don't know how to use the tool?

[goetz]

Because dependency walker only shows the dependencies of the exe or dll you load into it and the DLLs that it can reach.

So, let's suppose you have prog.exe that depends on fancy.dll and that fancy.dll depends on standard.dll then, if you do not have fancy.dll reachable bye depends.exe, it only shows that prog.exe depends on fancy.dll. As soon as you make fancy.dll reachable, it shows you that standard.dll is also needed.

[mzimmers]

Oh, so using it is something of an iterative process, then. Makes sense.

As far as copying these .dlls to the application directory, is it a simple matter of a file-system copy, or must these be handled in a special way?

[goetz]

Just a copy, nothing special you have to treat. You can put everything into a script (.bat or, if you have MSYS running, even a shell (bash) script) that makes this for you.

[mzimmers]

Is it possible to put the libraries in a subdirectory (the way one would with the plugins)? That would keep things a bit cleaner.

Or, I suppose, I could create a directory for runtime only...

[mzimmers]

Well, after playing with Dependency Walker for a bit, I now realize that I don't understand exactly how to use the information it supplies. How do I go about ensuring that I've locally supplied all necessary libraries? Do I need to remove or disable the paths to them in my PATH environment variable? Because it seems that DW will list them whether or not I've locally supplied them.

Also, I don't seem to have a file "libpthread-2.dll" on my system. I do have a "libpthread.a" which I take it is a static library. Should I move this over?

[john_god]

Perhaps the best way for you is forget about dependency walker for now.

Most Qt ddl you will need should be in C:\QtSDK\Desktop\Qt\4.7.4\mingw\bin . If you don't have this diretory in your system path, your program will not work outside QtCreator, i.e if you run the executable from file explorer.
Then create a new directory with your exe file, paste the files that Volker already told you, one by one, until your program starts working from the file explorer. Then you should have all the necessary files in that directory ready to go.
You can now zipped, or better, create a fancy setup.exe package. I usually use install creator (http://www.clickteam.com/website/usa/install-creator.html) but there are manny others and perhaps better programs to pack you software. It's very easy to use, and doenst require any scripting.

You could install dll files in windows system or system32 directory, thats usually the windows way of installing things, but that can cause some problems that I'm not going to talk about here, so perhaps it's best to keep it simple and install all dll files in the same directory of your exe file, usually C:\Program Files (x86)\your_program

[mzimmers]

Hey, John - thanks for the reply. A few notes:

I'm using 4.8.0, not 4.7.4.

I'm trying to get this working on a program that uses no QT libraries.

I still have an unidentified file (libpthread-2.dll)

probably because of #3, when I run the DW profiler, I get some output that looks rather unsuccessful. I'll postpone posting it until I get that last file that Volker mentioned resolved.

So, again, I'm kind of going for "proof of concept" here. I just want to know that I can make this work. Once I'm successful with this program, I'll start using the same technique with those that will use the Qt libraries. Right now, though, I'm stuck until I get that final file nailed down.

[goetz]

I don't use the SDK builds, but a stand alone MinGW installation + manually compiled Qt libs. I don't know the exact setup of the SDK and how all the libs are named there. But, all the needed DLLs are in the SDK, otherwise you wouldn't be able to run the apps from Qt Creator :-)

[mzimmers]

[quote author="Volker" date="1334132257"]I don't use the SDK builds, but a stand alone MinGW installation + manually compiled Qt libs. I don't know the exact setup of the SDK and how all the libs are named there. But, all the needed DLLs are in the SDK, otherwise you wouldn't be able to run the apps from Qt Creator :-)[/quote]

At present, my concern isn't whether the SDK supplies everything or not; it's whether I've successfully copied all files that are necessary to my executable's directory.

Again, since the SDK is in my PATH variable, how do I know that when my program needs a library, it's getting it from the local directory and not via PATH? Do I need to remove the SDK from PATH to test this?

I hope this makes sense; it's 4 AM here.

[goetz]

Ah, I see. To test without the SDK do not remove it, it's sufficient to just rename the toplevel directory (e.g. from QtSDK to QtSDK-Blocked) and the do the tests. That's what I do regularly. Don't forget to re-rename it afterwards, otherwise your builds will fail :-)

To see where your DLLs are from, you can switch dependency walker to show the full paths, instead of the filenames only (F9 if I remember correctly).

And as far as I remember, local DLLs take precedence over those in the PATH. Except for those that nee a manifest and where windows insists on them residing somewhere in a system directory. But this is neither true for MinGW nor the Qt DLLs.

[mzimmers]

Well, after so many false starts, I hesitate to claim victory, but it appears that it's working.

I'm still using a couple files from my \windows\syswow64 directory (KERNEL32.DLL and MSVCRT.DLL) but I imagine that's OK. (As a side note, that MSVCRT file isn't a Visual C file is it? I'd have no idea how that crept in there.)

I guess the acid test is to send this to someone without Qt and have them try it, huh?