Linker Problem with Msvc

[Christian Ehrlicher]

Thiago Macieira schrieb:
> Christian Ehrlicher wrote:
> 
>>Hi,
>>
>>once again an ugly linker problem with Msvc and kio (class MetaData in
>>global.h). It's the same like described here:
>>http://lists.trolltech.com/qt-interest/2005-12/thread00622-0.html
> 
> 
> And again it's caused by the fact that the MS compiler & linker don't 
> properly understand the concept of common functions and weak symbols. The 
> C++ standard allows for this, so both the linker and dynamic linker in 
> Win32 platforms should be modified to allow for them.
> 
> The problem here is akin to inline functions and I wouldn't be surprised 
> if it showed up with them. A function is defined in one .h and exported 
> from it (__declspec(dllexport)). It is inlined in two different objects 
> or shared objects. Therefore, both export the function.
It's 'only' the static inline function I when I've seen it correct.
> 
> When linking (statically or dynamically), the linker is expected to merge 
> those two functions. This isn't happening.
> 
> As a side note, gcc has a switch called -fvisibility-inlines-hidden for 
> similar issues.
I'll read msdn tomorrow to see if maybe msvc2005 knows something about
such things (but I think don't think so).
> 
> 
>>According to the reporter, I have to define something similar to this:
>>#ifdef Q_OS_WIN
>>template class __declspec(dllimport) QMap<QString, QString>;
>>#endif
> 
> 
> Which is ugly.
> 
> Can't you add a simple, forward declaration using Q_CORE_EXPORT? I.e., 
> lose the #ifdef and replace the __declspec with Q_CORE_EXPORT.
Have to play around how we can make it look better tomorrow.
> 
> In fact, come to think of it, one could propose to make ALL forward 
> declarations include the proper EXPORT attribute. I am not sure if this 
> would be wise, since classes can change libraries and this would require 
> updating the header files (all of them) when it happened.
> 
> But we could do it for all the templates, though.
> 
> 
>>But before I add this ugly hack, I wanted to know if MetaData has to be
>>exported or not. If not, I could skip this.
>>Or has someone another idea to fix this?
> 
> 
> It's possible to do without a new class called MetaData. We can simply 
> typedef QMap<QString, QString> to it and move the operator+= to a 
> non-member function.
> 
> BTW, shouldn't we be using a QHash instead?
Hah, this is what I wanted to hear :-D

Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051219/8b4b1cef/attachment.sig>