The case of linker unable to find symbol for QtService in MinGW-w64 when developing a Windows service based on QtWebApp

QtWebApp includes QtService for developer's sake when developing Windows service or Linux daemon. QtService is quite well made in many sense, but it's also "abandoned" by Qt Company for years.

I'm using mingw-builds, one of personal builds in MinGW-w64 project, to use the same compiler between Windows and Linux, as well as make use of easy portability. In recent development with QtWebApp I found out that if I dynamic-link QtWebApp the linker cannot find symbol for QtService<QCoreApplication>. As the version for GCC shipped with Qt 5.7 is 5.3 so it's not due to older compiler...... And I found a solution.

Open QtWebApp/qtservice/qtservice.h and find the line below.

template <typename Application>
class DECLSPEC QtService : public QtServiceBase

And I changed the line like this:

template <typename Application>
class /*DECLSPEC*/ QtService : public QtServiceBase

The DECLSPEC changes library header structure using #define. That is changed into either Q_DECL_EXPORT or Q_DECL_IMPORT, and unless it's the time to build the library itself, the value is always Q_DECL_EXPORT. The problem is that QtService is a template class, meaning that the symbol should be changed according to the template details, but if the function is declared as Q_DECL_EXPORT, the compiler assumes that necessary symbols are already built. If you see comment out that DECLSPEC and review the result of the compilation, you can see object file for the header file named qtservice.o.

Well, I had hard time to find this small thing, but I'm relieved that I found it quite quicker than expected. Now I can respect LPGL once again. :)