[solved] Questions on deployment
-
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
-
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.
-
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 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.
-
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.
-
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?
-
You could start with "Mission Accomplished" ;-)
msvcrt.dll is the microsoft C runtime library. It is used by MinGW too, as MinGW uses native Windows API. Kernel32.dll is ... the kernel :-) ... it's loaded by all applications, you must not copy that into the app directory.
What DLLs do you have in your application directory now?
For test purposes: I usually have a vanilla windows installation running in a virtual machine. You can install your stuff and roll back to a pristine snapshot once you're done.
-
[quote author="Volker" date="1334162833"]What DLLs do you have in your application directory now?[/quote]
- libgcc_s_dw2-1.dll
- libgomp-1.dll
- libpthread.a
- libstdc++6.dll
- mingwm10.dll
You suppose I should probably take msvcrt.dll, too?
-
This looks good. You do not need msvcrt.dll.
-
I'd originally marked this solved, but...I realized my job isn't quite finished here. Now that I've discovered all the files necessary to include in my distribution, is there a way to use the Deployment methods in the Run Settings to automatically copy the necessary files, and the executable, into a "delivery" directory that I can then zip and send to a customer?
-
Hm, maybe that's better asked as a new topic in the Tools forum.
-
Good enough...I'll ask over there. Thanks.
-
Well...here I thought I had this thing solved. Just tried it on a second application (copying over the same files) and...it doesn't run.
I've looked at the DW log, and it doesn't indicate any missing modules. The program runs OK within Creator. What else besides a missing library might cause the program not to run?
-
That's hard to say without knowing the actual setup. Do you get any error messages from windows?
-
Nope. If I double-click on the program from the GUI, it sits for a moment, but does nothing. If I try in invoke from the CLI, I get a prompt back immediately.
I think I found an issue: I copied my DLLs over from the directory with the program that worked, but according to DW, the two programs expect different libraries. One is from \windows\system32; the other from \windows\syswow64. I'm trying to look into that, but at the moment, Creator is giving me some grief that might be related to my downloading the newest release.
Guess I should nuke the build directories and start over?
-
Oh - looks like you mixed up 32bit and 64bit libraries and executables. This will lead to disaster - as you've noticed already :)
-
I don't know how I did that, though. According to DW, the two programs are using different libraries, but...I don't see any differences in my build settings.
I could go get the 64-bit libraries for the second program, but I'd rather fix my builds so they use the same ones.
-
I deleted and regenerated the build directories...same behavior.
I think my comment about \windows\system32 vs. \windows\syswow64 may have been a red herring. When I worked in DW and watched a bit more carefully, I noticed that BOTH programs begin with system32 in the dependency tree, but when I profile, BOTH change to syswow64. (This is odd, but I'm not sure it's related to my issue.) When I refresh, both revert to system32.
Both programs show identical dependencies.
Both programs have the mingw files MINGWM10.DLL and LIBGCC_S_DW1-2.DLL in their run directories.
But, one program runs, and the other doesn't. I'm kind of at a loss to explain this.
EDIT:
Another data point: I added the files:
- libgomp-1.dll
- libpthread.a
- libstdc++-6.dll
to the directory of the malfunctioning program (even though they weren't necessary for the one that works)...same results.
-
If anyone's willing to take a look, here's the DW log file after a profile:
"profile.txt":http://scopedin.com/data/profile.txt
I can't read these tea leaves, but perhaps someone else can.
-
Solution discovered, and documented "here.":http://qt-project.org/forums/viewthread/16470/
Thanks to everyone who replied.