What am I missing? Unresolved externals

Hi,

In porting to Qt4 I'm finally linking but run into unresolved externals:

Code:

---

link /LIBPATH:"C:\Qt\4.0.1\lib" /NOLOGO /DEBUG /DEBUG /DLL /LIBPATH:../xpaf /LIBPATH:../xpaf xpaf-sdk.lib /LIBPATH:..
/xpaf-sdk/debug /LIBPATH:../../lua-5.0.2/lib ../../lua-5.0.2/lib\lualib.lib C:\Qt\4.0.1\lib\QtCored4.lib C:\Qt\4.0.1\lib\QtGu
id4.lib C:\Qt\4.0.1\lib\Qt3Supportd4.lib C:\Qt\4.0.1\lib\QtSqld4.lib C:\Qt\4.0.1\lib\QtXmld4.lib /OUT:"debug\xpaf-sdkgui.dll"
 @C:\temp\nmCE6.tmp
   Creating library debug\xpaf-sdkgui.lib and object debug\xpaf-sdkgui.exp
moc_ezSessionApp.obj : error LNK2001: unresolved external symbol "public: static struct QMetaObject const ezCrm::ezBase::stat
icMetaObject" (?staticMetaObject@ezBase@ezCrm@@2UQMetaObject@@B)
...
...
ezModelGui.obj : error LNK2001: unresolved external symbol "public: static struct QMetaObject const layerModel::ezBCModel_RTa
ble_Control::staticMetaObject" (?staticMetaObject@ezBCModel_RTable_Control@layerModel@@2UQMetaObject@@B)
debug\xpaf-sdkgui.dll : fatal error LNK1120: 59 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\Bin\nmake.exe"' : return code '0x2'
Stop.

---

I have

Code:

---

// Win 32 DLL export macros
#ifdef WIN32
# ifdef BUILD_DLL
#  define XPAF_DLL_EXPORT  __declspec(dllexport)
# else
#  define XPAF_DLL_EXPORT  // Empty
# endif
#endif // WIN32

---

and

Code:

---

namespace layerModel {
 
class XPAF_DLL_EXPORT ezBCModel_RItem: public ezBCModelBase
{
	Q_OBJECT
public:
	ezBCModel_RItem(ezModelRender *aParent, QString aName=0);
	~ezBCModel_RItem(void);
};
...
namespace layerModel {
..
class XPAF_DLL_EXPORT ezBCModel_RTable: public ezBCModel_RItem
{
	Q_OBJECT
public:
	ezBCModel_RTable(ezModelRender *aParent, QString aName=0);
	~ezBCModel_RTable(void);
};

---

What am I missing? Namepace messing the name mangling :confused:
DLL_EXPORT :confused:

Any pointers appreciated!!

Does appropriate moc_*.cpp file contains the definition of layerModel::ezBCModel_RTable_Control::staticMetaOb ject?

In moc_ezBCModel_RTable.cpp:

Code:

---

const QMetaObject layerModel::ezBCModel_RTable_Control::staticMetaObject = {
    { &ezBCModel_RItem_Control::staticMetaObject, qt_meta_stringdata_layerModel__ezBCModel_RTable_Control,
      qt_meta_data_layerModel__ezBCModel_RTable_Control, 0 }
};

---

Do you link your application with moc_ezBCModel_RTable.obj?

Yup.. it gets linked into the DLL:

Code:

---

Creating temporary file "C:\temp\RSP00007A.rsp" with contents
[
/OUT:"debug\xpaf-sdk.dll" /NOLOGO /LIBPATH:"C:\Derick\projects\xpaf\xpaf-sdk\debug" /LIBPATH:"C:\Qt\4.0.1\lib" /DLL /DEBUG /SUBSYSTEM:WINDOWS /LIBPATH:../xpaf /LIBPATH:../xpaf /LIBPATH:../../lua-5.0.2/lib ../../lua-5.0.2/lib\lualib.lib C:\Qt\4.0.1\lib\QtCored4.lib C:\Qt\4.0.1\lib\QtGuid4.lib C:\Qt\4.0.1\lib\QtSqld4.lib C:\Qt\4.0.1\lib\QtXmld4.lib C:\Qt\4.0.1\lib\Qt3Supportd4.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
"\Derick\projects\xpaf\tmp\xpaf-sdk\ezBBase.obj"
"\Derick\projects\xpaf\tmp\xpaf-sdk\ezBCAucLot.obj"
"\Derick\projects\xpaf\tmp\xpaf-sdk\ezBCBase.obj"
"\Derick\projects\xpaf\tmp\xpaf-sdk\ezBCContact.obj"
"\Derick\projects\xpaf\tmp\xpaf-sdk\ezBCModel_BC.obj"
"\Derick\projects\xpaf\tmp\xpaf-sdk\ezBCModel_DTable.obj"
"\Derick\projects\xpaf\tmp\xpaf-sdk\ezBCModel_Entity.obj"
"\Derick\projects\xpaf\tmp\xpaf-sdk\ezBCModel_RItem.obj"
"\Derick\projects\xpaf\tmp\xpaf-sdk\ezBCModel_RScreen.obj"
"\Derick\projects\xpaf\tmp\xpaf-sdk\ezBCModel_RTable.obj"

---

Found something:

After undefining XPAF_DLL_EXPORT the unresolved externals went away...

Is there a difference in Qt4? I think I read somewhere that the moc now understands macro expantions.... :confused:

Does that class of yours inherit QObject?

Yes they do.

When I build the DLL my classes are not exported. I even tried to export my classes with:

# define XPAF_DLL_EXPORT Q_DECL_EXPORT
and
# define XPAF_DLL_EXPORT __declspec(dllexport)

Anything that I should try with QT4?

Does anybody have some sample classes exported in external DLLs? Please :)

My code compiles but I get an error as my DLL does not show the exported classes. Or do we need to load DEF files?

Check Qt4 sources :)

Maybe a more specific hint :) .. I only found some specific macros for plugins.

I even tried:

Code:

---

#include <QtCore/qglobal.h>
// Win 32 DLL export macros
#ifdef WIN32
# ifdef BUILD_DLL
//#  define XPAF_DLL_EXPORT  __declspec(dllexport)
#  define XPAF_DLL_EXPORT  Q_DECL_EXPORT
# else
#  define XPAF_DLL_EXPORT  // Empty
# endif
#endif // WIN32

---

Are you sure you pinpointed the problem correctly? It looks like your plugin can't resolve a symbol. I know it shouldn't even try to, but... It looks like an overall compiler issue not a Qt one. Try to build any plugin which needs an external dependency (for example one that needs a "foo()" function. When you succeed, you'll come back to Qt. Maybe you lack some compiler option?

Hmmm... after using:

Code:

---

#include <QtCore/qglobal.h>
#  define XPAF_DLL_EXPORT  Q_DECL_EXPORT

---

And the rebuild of the whole planet... one DLL worked .... :D phew....
Now to sort out the other...
It still is the same unresolved symbols so I'll check some defines...

Sigh ... still no joy...

When creating a 2nd DLL the imports of the 1st does not work:

Code:

---

ezGScreenInterface.obj : error LNK2001: unresolved external symbol "public: static struct QMetaObject const ezCrm::ezBase::staticMetaObject" (?staticMetaObject@ezBase@ezCrm@@2UQMetaObject@@B)

---

ezGScreenInterfac declated in 2nd DLL
ezBase declared in 1st DLL

Any idea why teh meta object does not get exported in the 1st DLL?

Quote:

---

Originally Posted by derick

When creating a 2nd DLL the imports of the 1st does not work:

---

When you compile code that will use your DLL (not the DLL itself), you need __declspec(dllimport) (in the same place where __declspec(dllexport) was).

I sorry, I am having a problem very similar to this, but when reading this thread I keep thinking, shouldn't Qt be abstracting all this?

Where in the Qt documentation does it say I need to have "dllexport", "dllimport" declarations everywhere?

Quote:

---

Originally Posted by Paul Drummond

Where in the Qt documentation does it say I need to have "dllexport", "dllimport" declarations everywhere?

---

Probably nowhere, it's specific only to windows DLLs --- normal systems doesn't require this.

Moreover what you should put before the class name depends on the way use use your code. If the header is used for compilation of a DLL, it should be dllexport, otherwise it should be dllimport, but how could Qt know this?

Something like this:

Code:

---

#ifdef Q_OS_WIN32
#   ifdef BUILD_DLL
#      define EXPORT __declspec(dllexport)
#   else
#      define EXPORT __declspec(dllimport)
#   endif
#else
#   define EXPORT
#endif

---

together with:

Code:

---

CONFIG(dll) {
   DEFINES += BUILD_DLL
}

---

in the .pro file should work.

There probably is some Qt macro to abstract this a little. The macro should expand to empty code on platforms other than Win32 and to that export macro on Windows

Quote:

---

Originally Posted by wysota

There probably is some Qt macro to abstract this a little.

---

Where? ;)

src/corelib/global/qglobal.h:# define Q_DECL_EXPORT __declspec(dllexport)

Code:

---

#ifndef Q_DECL_EXPORT
#  ifdef Q_OS_WIN
#    define Q_DECL_EXPORT __declspec(dllexport)
#  elif defined(QT_VISIBILITY_AVAILABLE)
#    define Q_DECL_EXPORT __attribute__((visibility("default")))
#  endif
#  ifndef Q_DECL_EXPORT
#    define Q_DECL_EXPORT
#  endif
#endif

---

Quote:

---

Originally Posted by wysota

src/corelib/global/qglobal.h:# define Q_DECL_EXPORT __declspec(dllexport)

Code:

---

#ifndef Q_DECL_EXPORT
#  ifdef Q_OS_WIN
#    define Q_DECL_EXPORT __declspec(dllexport)
#  elif defined(QT_VISIBILITY_AVAILABLE)
#    define Q_DECL_EXPORT __attribute__((visibility("default")))
#  endif
#  ifndef Q_DECL_EXPORT
#    define Q_DECL_EXPORT
#  endif
#endif

---

---

And where's __declspec(dllimport)?

Quote:

---

Originally Posted by jacek

And where's __declspec(dllimport)?

---

I didn't say there is.

Quote:

---

Originally Posted by wysota

I didn't say there is.

---

But in this case it's useless.

Quote:

---

Originally Posted by jacek

But in this case it's useless.

---

Not quite...

You can always redefine that macro (which doesn't change the fact that a need for such thing at all is just stupid) before including headers.

Code:

---

#ifdef Q_OS_WIN
#  ifdef Q_DECL_EXPORT
#    undef Q_DECL_EXPORT
#  endif
#  define Q_DECL_EXPORT __declspec(dllimport)
#endif
#include "somefile.h"
#undef Q_DECL_EXPORT

---

Anyway my point was that Qt helps a little with defining those macros. It helps source code to be more portable. I didn't say it (unfortunately) releases the user from knowing that OS-dependent little magic tricks.

Quote:

---

Originally Posted by wysota

Not quite...

You can always redefine that macro (which doesn't change the fact that a need for such thing at all is just stupid) before including headers.
[...]
Anyway my point was that Qt helps a little with defining those macros. It helps source code to be more portable.

---

So Qt provides an undocumented macro that you must redefine to able to use it. Well... I wouldn't call it helpfull. ;)

Quote:

---

Originally Posted by jacek

Probably nowhere, it's specific only to windows DLLs --- normal systems doesn't require this.

---

"normal systems". So I can make plugins for Windows which arn't dlls? I just want plugins to work on Windows - I don't care how!

Quote:

---

Originally Posted by Paul Drummond

"normal systems". So I can make plugins for Windows which arn't dlls? I just want plugins to work on Windows - I don't care how!

---

What Jacek meant was that well written systems don't require those macros, while Windows does ;)

Quote:

---

Originally Posted by jacek

Where? ;)

---

I believe it's Q_EXPORT (or at least it was in Qt3).

Then you define -D QT_DLL or -D QT_NODLL depending on whether you are linking with a dll or a static library.

Quote:

---

Originally Posted by Chicken Blood Machine

I believe it's Q_EXPORT (or at least it was in Qt3).

---

Yes it was in Qt3, but is there something similar in Qt4?

Quote:

---

Originally Posted by jacek

Yes it was in Qt3, but is there something similar in Qt4?

---

I've just checked my ported Qt4 code and I seem to be using Q_DECL_EXPORT

Quote:

---

Originally Posted by Chicken Blood Machine

I've just checked my ported Qt4 code and I seem to be using Q_DECL_EXPORT

---

OK, so there is Q_DECL_EXPORT and Q_DECL_IMPORT which are set correctly. The only missing thing is a single macro which will be set to Q_DECL_EXPORT or Q_DECL_IMPORT depending on whether you build DLL or application that uses it.

Something like this:

Code:

---

#ifdef QT_DLL
#   define EXPORT Q_DECL_EXPORT
#else
#   define EXPORT Q_DECL_IMPORT
#endif

---

Correct me if i'm wrong - but as far as i can tell, Q_DECL_EXPORT and Q_DECL_IMPORT are the macros used by Qt when building a plugin. From an aesthetic viewpoint you should use your own when building an off-the-shelf dynamic library.

If i want to build an dynamic library (let's call it mylib), i include the following header called MyLibDef.h in every class header file whose interface i want to be exported to the dll.

Code:

---

#ifndef MY_LIBDEF_H_
#define MY_LIBDEF_H_
 
#if defined(WIN32)
#  ifdef MY_LIB_DLL
#    define MY_LIB_DLLMAPPING __declspec(dllexport)
#  else
#    define MY_LIB_DLLMAPPING __declspec(dllimport)
#  endif
#else
#  define MY_LIB_DLLMAPPING
#endif
 
#endif

---

The class declarationt then looks like this:

Code:

---

class MY_LIB_DLLMAPPING Foo : public QWidget
...

---

I then add the -D MY_LIB_DLL to the compiler flags when i compile the dll. When i use the headers in some app that links the library the MY_LIB_DLL is not set by default ;) and everything is fine.

Cutting-and-pasting-and-replacing MY_LIB with something other takes approximately 30 seconds - IMHO this ain't that much ;)

Regarding the WIN32 symbol: I don't use qmake so it might be that WIN32 will not work but you can replace it with the symbol Q_OS_WIN spotted in one of the posts above.

Quote:

---

Originally Posted by orb9

Correct me if i'm wrong - but as far as i can tell, Q_DECL_EXPORT and Q_DECL_IMPORT are the macros used by Qt when building a plugin. From an aesthetic viewpoint you should use your own when building an off-the-shelf dynamic library.

If i want to build an dynamic library (let's call it mylib), i include the following header called MyLibDef.h in every class header file whose interface i want to be exported to the dll.

Code:

---

#ifndef MY_LIBDEF_H_
#define MY_LIBDEF_H_
 
#if defined(WIN32)
#  ifdef MY_LIB_DLL
#    define MY_LIB_DLLMAPPING __declspec(dllexport)
#  else
#    define MY_LIB_DLLMAPPING __declspec(dllimport)
#  endif
#else
#  define MY_LIB_DLLMAPPING
#endif
 
#endif

---

The class declarationt then looks like this:

Code:

---

class MY_LIB_DLLMAPPING Foo : public QWidget
...

---

I then add the -D MY_LIB_DLL to the compiler flags when i compile the dll. When i use the headers in some app that links the library the MY_LIB_DLL is not set by default ;) and everything is fine.

Cutting-and-pasting-and-replacing MY_LIB with something other takes approximately 30 seconds - IMHO this ain't that much ;)

Regarding the WIN32 symbol: I don't use qmake so it might be that WIN32 will not work but you can replace it with the symbol Q_OS_WIN spotted in one of the posts above.

---

I agree completely. This should probably be put in an FAQ for people coming over from the UNIX world.

I'm currently working with Windows dlls at work and I have to say I hate the crappy implementation that MS has. On unix, you generally don't even need to know whether you are linking with a shared library or an archive library and you don't need any 'clever' macros when writing the interface for a library either. OK - rant over - don't bother responding to this :mad:

Ok, I made some progress:

When I tried to build the mySQL plugin it just did not work. The n I rebuilt my whole Qt from source (not using qt-win-commercial-4.1.0-vs2003.exe) and it magically worked.

For the moment I use this in my PRO file and it works:

Code:

---

#Settings:
QT		+= qt3support xml sql
QT		-= gui
#CONFIG		+= dll
CONFIG		+= staticlib
#DEFINES 	+= BUILD_DLL 
#DLLDESTDIR	 = ../xpaf
DESTDIR	 	 = ../xpaf
TEMPLATE	 = lib
#Settings end

---

I'll revert back to DLLs soon and see how it goes.

Quote:

---

Originally Posted by Chicken Blood Machine

I'm currently working with Windows dlls at work and I have to say I hate the crappy implementation that MS has. On unix, you generally don't even need to know whether you are linking with a shared library or an archive library and you don't need any 'clever' macros when writing the interface for a library either. OK - rant over - don't bother responding to this :mad:

---

I don't like the dark side, too... but this time part of their stuff isn't that bad.
The __declspec(dllexport) directive tells the compiler to explicitly export the class from the DSO. This enables tuning of a DSO interface, which results in smaller compiled code, improved loading time, etc. This feature (even better ;) is available in >=gcc-3.4, too. See
http://gcc.gnu.org/wiki/Visibility
for more infos.

One of my problems:
My MS Visual Studio project files got overwritten by the Qt VS integration plugin making that the librarian skips my moc_*.obj files as the output directory changed.

Thanks to this thread:
http://www.qtcentre.org/forum/showthread.php?t=450

Quote:

---

Originally Posted by orb9

I don't like the dark side, too... but this time part of their stuff isn't that bad.
The __declspec(dllexport) directive tells the compiler to explicitly export the class from the DSO. This enables tuning of a DSO interface, which results in smaller compiled code, improved loading time, etc. This feature (even better ;) is available in >=gcc-3.4, too. See
http://gcc.gnu.org/wiki/Visibility
for more infos.

---

Hmm, I wasn't aware of that. You learn something new every day! Thanks for the info.

I'm sorry, but can someone please explain to me why all this isn't explained in the Qt documentation? When reading about plugins and QLibrary, the Troll's should state if the code won't work on a particular platform. If I developed a plugin in Linux I would expect it to work on all supported platforms WITHOUT CODE CHANGES. I would accept configuration and compilation issues, but this is a code modification which isn't acceptable IMO.

Quote:

---

Originally Posted by Paul Drummond

I'm sorry, but can someone please explain to me why all this isn't explained in the Qt documentation?

---

It isn't?

Quote:

---

On Windows you must also explicitly export the function from the DLL using the __declspec(dllexport) compiler directive, for example:
extern "C" MY_EXPORT int avg(int a, int b)
{
return (a + b) / 2;
}
with MY_EXPORT defined as
#ifdef Q_WS_WIN
#define MY_EXPORT __declspec(dllexport)
#else
#define MY_EXPORT
#endif

---

Well... one might expect that this should be placed in different parts of the documentation too, but you can't say it isn't explained ;)

Anyway, the Trolls are responsible for the documentation, so you should ask them, not users of this forum.

Quote:

---

Originally Posted by jacek

Well... one might expect that this should be placed in different parts of the documentation too, but you can't say it isn't explained ;)

---

Okay, sorry I missed that but it is hidden away! Besides, when writing plugins there is no need to ever look up the documentation for QLibrary - this information should be mentioned in the plugin documentation.

Quote:

---

Originally Posted by jacek

Anyway, the Trolls are responsible for the documentation, so you should ask them, not users of this forum.

---

Come on, seriously! The Trolls are also responsible for the code, should I reserve code questions for them also?

Anyway, thankyou for pointing me to the documentation in QLibrary - that's all I was after!

Quote:

---

Originally Posted by Paul Drummond

Come on, seriously! The Trolls are also responsible for the code, should I reserve code questions for them also?

---

What Jacek meant was that you should ask them (and not us) why they did or didn't place anything in the documentation. We're not sightseers, Trolls don't tell us about everything they do ;)

And about code questions -- yes, if you want to know why they did something in a particular way, it's best to ask them. And some of the Trolls are present on this forum (although I fear none of the core programmers, but I might be wrong), so it shouldn't be too hard :) They are friendly people and do answer questions...

We answer mostly questions "what to do to achieve that" or "why doesn't it work". We often don't have the knowledge to answer why a particular design was chosen by TT.

Quote:

---

Originally Posted by wysota

What Jacek meant was that you should ask them (and not us) why they did or didn't place anything in the documentation. We're not sightseers, Trolls don't tell us about everything they do ;)

---

When you say I should ask them do you mean post to qt-interest or email the trolls directly?

If you mean ask them directly then that would be a private discussion and others wouldn't benefit from any solution or advice the trolls gave me. By voicing oppinion on this public forum others are able to gain from the advice, progress, etc.

If you mean ask qt-interest, then fine - I will. I can't access qt-interest from work that's all and I prefer internet forums such as QtCentre but I didn't realise you couldn't voice oppinion on this forum - I won't do it again :confused:

Anyway, this is getting off-topic. Sorry if I've upset anyone or asked the wrong questions.

Quote:

---

Originally Posted by Paul Drummond

When you say I should ask them do you mean post to qt-interest or email the trolls directly?

---

It's your choice. Mailing TT directly will probably yield a more complete answer, especially if you're lucky and ask a proper person :)

Quote:

---

If you mean ask them directly then that would be a private discussion and others wouldn't benefit from any solution or advice the trolls gave me. By voicing oppinion on this public forum others are able to gain from the advice, progress, etc.

---

Yes, of course. But nobody said you can't post results of that conversation here.

Quote:

---

If you mean ask qt-interest, then fine - I will. I can't access qt-interest from work that's all and I prefer internet forums such as QtCentre but I didn't realise you couldn't voice oppinion on this forum - I won't do it again :confused:

---

Of course you can express your opinions on the forum. Did anyone forbid you from doing that? We just said we don't know why TT prefers one solution over another. On the other hand you didn't exactly express a neutral opinion. You were complaining TT didn't do something and said TT should do it without checking if they already did.

Quote:

---

Anyway, this is getting off-topic.

---

I assure you there are threads which are way off more offtopic than this one :)

Quote:

---

Sorry if I've upset anyone or asked the wrong questions.

---

I'm sure you didn't upset anyone. And there are no wrong questions (although some may be very trivial). Jacek just said you were asking wrong people :)

Quote:

---

Originally Posted by wysota

Of course you can express your opinions on the forum. Did anyone forbid you from doing that? Jacek just said you were asking wrong people :)

---

I understand what you are saying but if I were to follow your advice I would never use this forum again! I should just email TT when I have a problem, then post the results to this forum! :) How do I know if my questions are inappropriate for this forum or not? If I ask them here and you guys say "Sorry, no idea - ask TT", then that's exactly what I will do :)

Anyway, forget it - I totally understand your point - I just like having the last word ;)

Quote:

---

Originally Posted by Paul Drummond

I'm sorry, but can someone please explain to me why all this isn't explained in the Qt documentation? When reading about plugins and QLibrary, the Troll's should state if the code won't work on a particular platform. If I developed a plugin in Linux I would expect it to work on all supported platforms WITHOUT CODE CHANGES. I would accept configuration and compilation issues, but this is a code modification which isn't acceptable IMO.

---

If you set up the export macro as instructed, you wont need code changes.

Quote:

---

Originally Posted by Chicken Blood Machine

If you set up the export macro as instructed, you wont need code changes.

---

True, my point was that it's not clear from the plugin documentation that the macros are needed and it certainly isn't stated in the tutorial steps ( http://doc.trolltech.com/4.1/plugins...t-applications).

Come to think of it does the plug&paint example doesn't use the macros either, even on Windows. What's that about???? :confused:

Quote:

---

Originally Posted by Paul Drummond

Come to think of it does the plug&paint example doesn't use the macros either, even on Windows. What's that about???? :confused:

---

Here's an answer from one of the Qt Quaterly articles:

Quote:

---

In most cases, exporting the plugin in this way is sufficient to ensure that Qt Designer and other applications can access the widget when using uic or with Qt's dynamic form loading facilities. If you want to use the custom widget directly by linking your application against the plugin, you must export the custom widget class explicitly

---

I have a same error. I solve the problem like this;) :

Code:

---

class DLLEXPORT_MODULE1 module1{
   .....
};
 
class DLLEXPORT_MODULE2 module2{
   .....
};
 
 .
 .
 .
#ifdef DLLBUILD_MODULE1
    #define DLLEXPORT_MODULE1 __declspec(dllexport)
#else
   #define DLLEXPORT_MODULE1
#endif
 
#ifdef DLLBUILD_MODULE2
    #define DLLEXPORT_MODULE2 __declspec(dllexport)
#else
   #define DLLEXPORT_MODULE2
#endif

---

You just need to stick this in a <your project>_globaL.h file and include it in you entry point class:

Code:

---

#include <Qt/qglobal.h>
 
#ifdef QTTIFFIMAGEHANDLER_LIB
# define QTTIFFIMAGEHANDLER_EXPORT Q_DECL_EXPORT
#else
# define QTTIFFIMAGEHANDLER_EXPORT Q_DECL_IMPORT
#endif

---

I've created a Qt Library project with the VS integration and that's the only win32 specific stuff that you need to create a dll.
It also is likely to depend on other project options, but this is the only reference you need to the DLL_EXPORT macros.

Q_DECL_EXPORT is just a redefined wrapper to DLL_EXPORT, similar I spose in the UINT16 idea that MS tend to use.
Redefine everything to make them non specific ;)

I hope this helps someone.