[Qt-interest] LNK2001: unresolved external symbol "private: __cdecl QObject::QObject(class QObject const &)"

[Stuart Longland]

Hi all,

I'm trying to compile an application in Visual Studio 2008 for a Windows
CE device (Psion WorkAbout PRO to be exact).  For whatever reason, the
link fails with just *one* of my classes.  Not any of the others derived
from QObject.

I'm having trouble seeing what I've done "special" that it doesn't like.
 The linker error I get, along with command line used is as follows:

> sh scripts/sdkenv.sh link.exe  /LIBPATH:"C:\devel\Qt\4.7.1-PsionTeklogix-ARMV4I\
> lib" /NOLOGO /NODEFAULTLIB:OLDNAMES.LIB /INCREMENTAL:NO /SUBSYSTEM:WINDOWSCE,5.0
> 0 /MACHINE:THUMB /DYNAMICBASE /NODEFAULTLIB:secchk.lib -OUT:ptrakqt.exe @ptrakqt
> .lst
> SOAPClient.obj : error LNK2001: unresolved external symbol "private: __cdecl QOb
> ject::QObject(class QObject const &)" (??0QObject@@AAA at ABV0@@Z)
> ptrakqt.exe : fatal error LNK1120: 1 unresolved externals
> make: *** [ptrakqt.exe] Error 96

My build environment is based on Cygwin; using its make binary to
orchestrate the build process.  autotools configures the build setting
the path to the Qt library, where Visual Studio is installed, path to
the gSOAP library sources...etc.

The Makefiles then generate the sdkenv.sh which just sets environment
variables for cl.exe and link.exe (and initially; checksdk.exe).

I tried using qmake early on, but couldn't figure out how to make it
perform some custom steps, so I chickened out and went with what I knew.
 The same build environment works flawlessly on Linux and MacOS X (both
using gcc).

It's only Windows CE/Visual C++ that's giving me grief... and I think
I've built enough of it to suggest that it's not necessarily my calls to
cl.exe that are causing problems.

My searches have suggested problems relating to a lack of a QObject
include[1] or a missed compiler flag when linking a DLL[2].  I am
linking a user application (not a DLL), and as can be seen, the affected
class includes QObject as the very first include directive.  The
Q_OBJECT macro is also present.

(For anyone that's curious; this is a wrapper class around a
gSOAP-produced proxy class.)

> #ifndef _PTRAKSOAP_H
> #define _PTRAKSOAP_H
> 
> /*!
>  * PTrak SOAP interface for Qt
>  */
> 
> #include <QObject>
> #include <QString>
> 
> #include "soapPTrakProxy.h"
> #include "data/LoginResponse.h"
> #include "data/UnidentifiedResponse.h"
> #include "data/Request.h"
> 
> namespace PTrak {
> 	namespace SOAP {
> 		class SOAPClient : public QObject {
> 			Q_OBJECT
> 			public:
> 				SOAPClient(const QString& endpoint,
> 						int io_timeout = 60,
> 						QObject* parent = 0);
> 				~SOAPClient();
> 
> 				/*!
> 				 * Connect to the PTrak instance.
> 				 */
> 				PTrak::SOAP::LoginResponse* pt_connect(
> 						const QString& moduleCode,
> 						const QString& username,
> 						const QString& password);
> 
> 				/*! Close the connection */
> 				int pt_close();
> 
> 				/*! Send prepared PTrak Request */
> 				QVector<PTrak::SOAP::Response*> pt_request(
> 						PTrak::SOAP::Request* req);
> 
> 				/*! Send a request for more data */
> 				QVector<PTrak::SOAP::Response*> pt_requestMore(int ttl);
> 
> 			private:
> 				PTrakProxy*	proxy;
> 		};
> 	}
> }
> #endif

The Makefiles pass this to `moc` to generate SOAPClient-moc.cpp; and
both of these get compiled and linked in the output.  For whatever
reason, _something_ is trying to get at this private copy constructor
for QObject.  I'm not calling it explicitly in my code, but somehow, a
reference to this constructor winds up in SOAPClient.obj.

> ----- Build information -----
> Building for: wince arm msvc
> 
> Qt installed at: /cygdrive/c/devel/Qt/4.7.1-PsionTeklogix-ARMV4I
> 
> C compiler flags:
> C++ compiler flags: /FD /EHsc /MD /GS- /fp:fast /Zc:wchar_t- /GR- /W3 /nologo /T
> P
> C preprocessor flags:  -D"UNDER_CE" -D"WINCE" -D"_WINDOWS" -D"_UNICODE" -D"UNICO
> DE" -D"_WIN32" -D"QT_NO_PRINTER" -D"QT_NO_PRINTDIALOG" -D"STANDARDSHELL_UI_MODEL
> " -D"_WIN32_WCE=0x500" -D"ARMV4I" -D"_ARMV4I_" -D"armv4i" -D"_ARM_" -D"ARM" -D"_
> M_ARM" -D"__arm__" -D"Q_OS_WINCE_STD" -D"QT_NO_CURSOR" -D"QT_NO_DEBUG" -D"NDEBUG
> " -D"QT_CORE_LIB" -D"QT_GUI_LIB" -D"__func__=__FUNCTION__" -D"_WIN32_WCE" -DWITH
> _COOKIES -DWITH_NONAMESPACES -DWITH_NOZONE -DDEBUG_SOCKET -I"C:\\devel\\Qt\\4.7.
> 1-PsionTeklogix-ARMV4I\\include" -I"C:\\devel\\Qt\\4.7.1-PsionTeklogix-ARMV4I\\i
> nclude\\QtCore" -I"C:\\devel\\Qt\\4.7.1-PsionTeklogix-ARMV4I\\include\\QtGui" -I
> "H:\\stuartl\\vrt\\projects\\ptrak\\trunk\\client\\prodtrackCE\\soap\\stdsoap2"
> -I"H:\\stuartl\\vrt\\projects\\prodtrakQT\\wcecompat" -IH:\\stuartl\\vrt\\projec
> ts\\prodtrakQT -D__func__=__FUNCTION__
> Linker flags:  /LIBPATH:"C:\devel\Qt\4.7.1-PsionTeklogix-ARMV4I\lib" /NOLOGO /NO
> DEFAULTLIB:OLDNAMES.LIB /INCREMENTAL:NO /SUBSYSTEM:WINDOWSCE,5.00 /MACHINE:THUMB
>  /DYNAMICBASE /NODEFAULTLIB:secchk.lib
> Libraries:  qtmain.lib QtCore4.lib QtGui4.lib coredll.lib corelibc.lib ole32.lib
>  oleaut32.lib uuid.lib commctrl.lib ws2.lib

The C Preprocessor flags are shared between `moc`, `cl.exe` and `gcc` (I
use `gcc -MM` to generate dependency files).  The settings were copied
and pasted from working projects, so I think they should be correct, but
clearly I've missed something.

I am able to build the demos for Qt, as well as simple custom
applications in Visual Studio, just not *this* application, which builds
fine in gcc.  Does anyone have any clues as to what I've missed?

Thanks in advance.
Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

1. http://lists.trolltech.com/qt-interest/2008-08/thread00396-0.html
2. http://lists.trolltech.com/qt-interest/2008-03/thread00099-0.html