Installing, compressing and being dynamic
Ariya and I have had a discussion on whether SpeedCrunch can be built as a statically linked executable on Windows, and if that is a useful thing to have. Ariya has also wanted to try using the UPX binary compression tool on SpeedCrunch. Tonight I sat down and played around with this and these are my findings:
#1 On Windows, we will always require an installer for some users. That is because we need to create start menu entries and such. Perhaps a platform specific part of SpeedCrunch could do this when executed the first time - but an Installer is still nice to have (it also brings and uninstaller which has proven very nice on Windows).
#2 A statically executable for Windows is also nice. Portable applications are gaining popularity and some users are satisfied with a single exe file instead of installing something.
#3 I have not succeded (yet) when it comes to building a Qt environment for Windows that yeilds executables not depending on mingwm10.dll. This has to be solved before the executable can be distributed all alone.
#4 Using UPX on the statically compiled executable brings it from 9 613 312 bytes to 3 182 592 bytes. I bet that I can save even more space by having a think when I configure Qt. (The installer for the dynamically linked version is 4 546 560 bytes).
posted by Johan Thelin @ 18:55
12 comments
12 Comments:
Being a portable app doesn't mean a single exe. It is more to do with not relying on any registered components, and not storing your settings in the registry. If you use QSettings, make sure to specify the ini file backend, and have it stored in the application directory, instead of the registry backend, which is the default.
As for the mingwm10 issue, I already emailed you about that.
Please, blog about your final solution, as I have a very similar problem. My findings:
- mingw dll cannot be avoided
- compile static qt with -Os (edit qmake.conf)
- disable exceptions and rtti
- disable all styles except win-classic and winxp
- inno setup is much nicer (more highlevel) than nullsoft i., but nullsoft has a lot of plugins
#1 nsis or innosetup, the most used free installers. (Personnaly, i prefer nsis, but it just a question of taste).
#2 This the 1st time i heared about portable applications. I didn't think that it's an important point or make speedcrunch more popular...
#3 i'll distribute the dll's with the apps.
#4 UPX is really nice :)
my 2 cts ;)
I'd like to point out that you can have sweet single-executable installers for Unix systems as well, at least those using ELF.
Simply build a Qt-based graphical setup program, statically linked. Then use http://ktown.kde.org/~frerich/elfrc.html to link the setup program and any data files you might want to process together to get a single resulting binary with all data files compiled in. Then use UPX on that.
Coolness. :-)
Ok, for the benefit of Anonymous, this is how you get rid of mingwm10.dll.
Edit the file $QTDIR\mkspecs\win32-g++\qmake.conf and remove all instances of -mthreads. Then recompile your app. The mingwm10.dll is no longer a dependancy.
Disclaimer: No-one seems to be entirely sure what that DLL is there for. The best explanation I've seen is that it has something to do with propagating exceptions in multithreaded programs. However, Qt doesn't use exceptions, so unless you use them yourself, it shouldn't be a problem. I haven't had any problems with the DLL removed, and many others have reported smooth sailing as well. However, this could create problems if you use exceptions and threads in your program.
#1: IMO we should always provide two versions: installer and portable.
#2: And for the portable version, don't build with registry support by default.
#3: I have been using the same trick that Leo mentioned, that works well.
#4: Possible we can further reduce this, once (version 0.9?) SpeedCrunch is fully Qt4-ified, i.e. no more stuff from Qt3support.
> #1 On Windows, we will always require an installer for some users.
Bundling has always been a key strength of Microsoft and KDE needs a distribution for windows. This follows through on the idea of needing an installer for some users and is intended to make it as easy as possible for users to use as many KDE applications and therefore as much free software as possible. I do hope KDE can avoid the user unfriendliness of multipart installers GTK programs like the GIMP inflicted on users.
Sure there will also be demand for smaller lighter portable apps but a great big bundle of QT and KDE apps will help promote the toolkit and platform rather than just promoting the individual applications.
I have used NSIS quite a lot and it seems very popular among developers of Free Software on Windows but it isn't so important which you choose so long as QT/KDE developers can pick the same thing and cooperate on reusing each others installers in a consistent way.
Building an installer for windows is trivial with InnoSetup. If you need help, let me know, I can do that in 30 minutes. I have found NSIS to be more powerful but 10 times more complicated.
And the simple way to do it is simply to install everything (DLL and exe and data) in the same directory and not worry about static linking.
SpeedCrunch currently uses InnoSetup and the approach that Leo describes.
Hmm... said Leo, meant BlueBird - sorry
Just for clarity, seems that some misunderstood what Johan has written.
We have a perfectly working Win32 Inno Setup-based installer since some time. And likely we won't get rid of it. This installer also install all the required DLLs.
The points Johan explained are about finding the possibility of having just one as-small-as-possible, no-registry-access, ready-to-run EXE file, without any dependency on any DLLs, as *an alternative* for the users who want it.
Thanks Ariya - that clarified things.
Post a Comment
<< Home