[Interest] Link Errors when Creating a Windows DLL containing Qt Widgets

[Michael Jackson]

On May 14, 2012, at 11:49 AM, Till Oliver Knoll wrote:

> 2012/5/14 Michael Jackson <imikejackson at gmail.com>:
>>> ...
>>> Could it be that it needs to be:
>>> 
>>> PipelineBuilderLib_EXPORT class WFilterWidget : public ...
>>> 
>>> instead?
>>> ...
>> Putting "PipelineBuilderLib_EXPORT" before the "class" keyword just results in a bunch of compiler warnings
> 
> Ah sorry, my wrong:
> 
>  http://msdn.microsoft.com/en-us/library/a90k134d%28v=vs.80%29.aspx
> 
> I usually define a simple *.h. For instance if my DLL was called Foo I
> would have FooLib.h with simply:
> 
> #ifndef FOOLIB_H
> #define FOOLIB_H
> 
> #include <QtCore/QtGlobal>
> #ifdef FOO_EXPORT
> # define FOO_API Q_DECL_EXPORT
> #else
> # define FOO_API Q_DECL_IMPORT
> #endif
> 
> #endif
> 
> Note the usage of Q_DECL_EXPORT|IMPORT (defined in <QtCore/QtGlobal>)
> which automagically gets rendered as this MSVC-specific
> __declspec-stuff, and to appropriate "export" declarations (or mostly
> "nothing") everywhere else (so not sure whether it gets rendered as
> __attribute__ ((visibility("default"))) on Linux, but we'll leave that
> away for now for simplicity).
> 
> 
> In the actual implementation header Foo.h:
> 
> #include "FooLib.h"
> 
> class FOO_API Foo : public QObject {
>  Q_OBJECT
> public:
>  ...
> };
> 
> I prefer:
> 
> class Foo : public QObject {
>  Q_OBJECT
> public:
>  FOO_API Foo(); // c'tor
>  FOO_API virtual ~Foo();
> 
>  FOO_API void exportedMethod();
>  void notVisibleOutsideOfDLL();
> 
> signal:
>  void someSignalWhichCanAlsoBeConnectedFromOutsideOfThisDLL();
> 
> protected:
>  FOO_API void canBeOverwrittenWithClassesInOtherLibraries();
>  void canOnlyBeOverwrittenInThisLibrary();
>  ...
> };
> 
> 
> Off course you then define FOO_EXPORT when you build the DLL, but
> DON'T define it when building everything else. This works
> cross-platform, including to connecting the above signal to some slot
> in another library/executable ("signals across DLL boundaries").
> 
> Cheers, Oliver
> 

This was a nice discussion but evidently a complete rebuild of my project solved the link errors so VS was not picking up some subtle change in my source code enough to regenerate all the proper build products. Chalk this up to "live and learn".

Thanks for the sanity checks and sorry for the noise.

Mike Jackson