What am I missing? Unresolved externals

[derick]

Hi,

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



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@layerM odel@@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

// 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


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!!

[jacek]

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

[derick]

In moc_ezBCModel_RTable.cpp:


const QMetaObject layerModel::ezBCModel_RTable_Control::staticMetaOb ject = {
{ &ezBCModel_RItem_Control::staticMetaObject, qt_meta_stringdata_layerModel__ezBCModel_RTable_Co ntrol,
qt_meta_data_layerModel__ezBCModel_RTable_Control, 0 }
};

[jacek]

Do you link your application with moc_ezBCModel_RTable.obj?

[derick]

Yup.. it gets linked into the DLL:



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"

[derick]

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:

[wysota]

Does that class of yours inherit QObject?

[derick]

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?

[derick]

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?

[wysota]

Check Qt4 sources :)

[derick]

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

[derick]

I even tried:



#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

[wysota]

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?

[derick]

Hmmm... after using:


#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...

[derick]

Sigh ... still no joy...

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


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?

[jacek]

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).

[Paul Drummond]

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?

[jacek]

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:

#ifdef Q_OS_WIN32
# ifdef BUILD_DLL
# define EXPORT __declspec(dllexport)
# else
# define EXPORT __declspec(dllimport)
# endif
#else
# define EXPORT
#endif
together with:
CONFIG(dll) {
DEFINES += BUILD_DLL
}in the .pro file should work.

[wysota]

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

[jacek]

There probably is some Qt macro to abstract this a little.
Where? ;)

[wysota]

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


#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

[jacek]

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


#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)?

[wysota]

And where's __declspec(dllimport)?

I didn't say there is.

[jacek]

I didn't say there is.
But in this case it's useless.

[wysota]

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.


#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.

[jacek]

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. ;)

[Paul Drummond]

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!

[wysota]

"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 ;)

[Chicken Blood Machine]

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.

[jacek]

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?

[Chicken Blood Machine]

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

[jacek]

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:
#ifdef QT_DLL
# define EXPORT Q_DECL_EXPORT
#else
# define EXPORT Q_DECL_IMPORT
#endif

[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.


#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:


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.

[Chicken Blood Machine]

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.


#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:


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:

[derick]

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:


#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.

[orb9]

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.

[derick]

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

[Chicken Blood Machine]

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.

[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.

[jacek]

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

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.

[Paul Drummond]

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.



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!

[wysota]

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.

[Paul Drummond]

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.

[wysota]

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 :)


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.


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.


Anyway, this is getting off-topic.
I assure you there are threads which are way off more offtopic than this one :)

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 :)

[Paul Drummond]

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 ;)

[Chicken Blood Machine]

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.

[Paul Drummond]

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-howto.html#the-lower-level-api-extending-qt-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:

[jacek]

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 (http://doc.trolltech.com/qq/qq16-designer.html):

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

[liang.2000]

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


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

[stevey]

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


#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.