Finally, just before giving up, I found this article:
http://qt-project.org/wiki/How-to-build-a-static-Qt-for-Windows-MinGW
After securing that I had Powershell and 7-zip installed, I downloaded the script and started the build process again over the work day. After some reconfigurations, where I specified where Qt creator should look for the compiler, I was finally able to create static executables (16 Mb)!
Saturday 18 October 2014
Saturday 11 October 2014
Qt: Static Linking - Nine ways to fail rebuilding Qt to enable static builds...
The case of static building for Qt is discussed below. With Qt installed, the environment provides the needed DLL-s automatically.
Specifying the DLL-s separately for deployment on a non-Qt environment is very complicated. If I'll deploy my projects in the future, that will most likely be in a single exe file, possibly with some resource files. Therefore, I need to get the static deployment working.
To make this possible, the entire Qt source code needed to be recompiled. This process takes many hours.
Initially, I had Qt installed with the compiler set to Microsoft Visual Studio Express 2013, and having the 64-bit version of Qt installed.
After several hours of compiling all the source code, the compilation process crashed. The first issue was that plugins such as SQL didn't compile during the rebuild of Qt. This is a major issue for deploying applications.
At the next attempt (re-installing Qt and rebuilding it with SQL disabled), I got another crash after five hours, complaining that a LIB file was missing. I even tried to reverse-engineer the LIB file from the dll file, but that wasn't successful either.
Even after following the instructions at
http://doc-snapshot.qt-project.org/qtifw-master/ifw-getting-started.html#configuring-qt
the compilation crashed, this time since a stddev.h file wasn't accepted by the compiler.
I tried with both 64/32-bit versions and MinGW32 (Minimalist GNU for Windows) and Microsoft Visual Studio-based Qt framework, without any luck.
This process took me several days. Why mentioning it on the blog? One central part of software development is all the dead-ends and failures in setting up the development environment. For hobby projects it isn't as critical as in commercial projects, where the developer sometimes need to explain for the stakeholders why he/she has spent several days, barking on the wrong tree.
I'll post the success-story in the next blog post.
Specifying the DLL-s separately for deployment on a non-Qt environment is very complicated. If I'll deploy my projects in the future, that will most likely be in a single exe file, possibly with some resource files. Therefore, I need to get the static deployment working.
To make this possible, the entire Qt source code needed to be recompiled. This process takes many hours.
Initially, I had Qt installed with the compiler set to Microsoft Visual Studio Express 2013, and having the 64-bit version of Qt installed.
After several hours of compiling all the source code, the compilation process crashed. The first issue was that plugins such as SQL didn't compile during the rebuild of Qt. This is a major issue for deploying applications.
At the next attempt (re-installing Qt and rebuilding it with SQL disabled), I got another crash after five hours, complaining that a LIB file was missing. I even tried to reverse-engineer the LIB file from the dll file, but that wasn't successful either.
Even after following the instructions at
http://doc-snapshot.qt-project.org/qtifw-master/ifw-getting-started.html#configuring-qt
the compilation crashed, this time since a stddev.h file wasn't accepted by the compiler.
I tried with both 64/32-bit versions and MinGW32 (Minimalist GNU for Windows) and Microsoft Visual Studio-based Qt framework, without any luck.
This process took me several days. Why mentioning it on the blog? One central part of software development is all the dead-ends and failures in setting up the development environment. For hobby projects it isn't as critical as in commercial projects, where the developer sometimes need to explain for the stakeholders why he/she has spent several days, barking on the wrong tree.
I'll post the success-story in the next blog post.
Tuesday 7 October 2014
Qt: Static and Dynamic linking for deployment of applications
Almost all software is developed using some pre-existing software, so that the developer doesn't need to invent the wheel again.
These pieces of software are imported in different manners to the final program. This may be:
In Windows, that code is compiled to DLL files (Dynamically Linked Library). Other operating systems such as Linux has similar libraries.
Put simply, In order to deploy software and make it useful for others, there are two options: static and dynamic linking.
Static linking will bring the libraries into the exe file (~10-20 Mb). If many program files on a system will need the same libraries, there will be a lot of redundant code in the different executables.
Dynamic linking will make the program refer to DLL files for the needed external code. This results in a smaller exe files (~100kb), but that will be dependent on external DLL files. I'm sure that my readers has got their fair share of dll errors.
The program Dependency Walker can be very helpful when finding what DLL files (and what versions) are needed for a program. Still, a lot of work and frustration lies ahead.
In the next blog post I'll describe what problems I saw when I tried building my program statically. Actually, I needed to recompile the entire Qt installation from its sources, and that's where I got the problems.
Until then, I can recommend VoidRealms/Bryan Cairns Youtube videos about DLL:s
These pieces of software are imported in different manners to the final program. This may be:
- Software that polls the keyboard and sends a corresponding character to the buffer/stdin,
- Software that keeps track of the mouse pointer
- Software that manages database connections
- Software that sets up the user interface, such as the "Open file" window.
- Software that handles networks
- Software that handles databases
- ...
In Windows, that code is compiled to DLL files (Dynamically Linked Library). Other operating systems such as Linux has similar libraries.
Put simply, In order to deploy software and make it useful for others, there are two options: static and dynamic linking.
Static linking will bring the libraries into the exe file (~10-20 Mb). If many program files on a system will need the same libraries, there will be a lot of redundant code in the different executables.
Dynamic linking will make the program refer to DLL files for the needed external code. This results in a smaller exe files (~100kb), but that will be dependent on external DLL files. I'm sure that my readers has got their fair share of dll errors.
Text in Swedish, but the message is clear:
spend hours chasing DLLs or consider another program.
The program Dependency Walker can be very helpful when finding what DLL files (and what versions) are needed for a program. Still, a lot of work and frustration lies ahead.
In the next blog post I'll describe what problems I saw when I tried building my program statically. Actually, I needed to recompile the entire Qt installation from its sources, and that's where I got the problems.
Until then, I can recommend VoidRealms/Bryan Cairns Youtube videos about DLL:s
Wednesday 1 October 2014
|| AND &&: Why it is a good idea to quibble
I had to recover my Windows 8 installation one week ago, and in that process, I re-installed Qt. This time, I also included the Microsoft Visual Studio Express compiling option for Qt.
After doing that, I tried to rebuild my programs TrafficControl and StockReader. I got houndreds of strange compiler errors that I didn't expect since the programs compiled without warnings before.
The issue was that I used the keywords "and" and "or" in several if clauses. Those keywords are allowed by gcc/g++ (GNU Compiler Collection), but not by Microsoft Visual Studio 2013: http://msdn.microsoft.com/en-us/library/2e6a4at9.aspx
My personal preference would have been to use AND and OR for logical keywords - that would have kept my source code as similar to human language as possible. But I also want my source code to be portable between different operating systems and compilers. So from now on, I'll continue with using the ||, && and != operators instead of OR, AND and NOT.
I still have some problems making static builds for my programs. More about that in future blog posts.
After doing that, I tried to rebuild my programs TrafficControl and StockReader. I got houndreds of strange compiler errors that I didn't expect since the programs compiled without warnings before.
The issue was that I used the keywords "and" and "or" in several if clauses. Those keywords are allowed by gcc/g++ (GNU Compiler Collection), but not by Microsoft Visual Studio 2013: http://msdn.microsoft.com/en-us/library/2e6a4at9.aspx
My personal preference would have been to use AND and OR for logical keywords - that would have kept my source code as similar to human language as possible. But I also want my source code to be portable between different operating systems and compilers. So from now on, I'll continue with using the ||, && and != operators instead of OR, AND and NOT.
I still have some problems making static builds for my programs. More about that in future blog posts.
Subscribe to:
Posts (Atom)