windows build

[Peter Kümmel]

Thiago Macieira wrote:
> Christian Ehrlicher wrote:
>> Q_CORE_EXPORT is correct - it must be an export in *every* lib it is
>> used (because of this it's KDE_EXPORT and not KIO_EXPORT)
> 
> Then no, this isn't the same at all. Q_CORE_EXPORT means export from 
> QtCore (which is where QList comes from and, more to the point 
> QVariantList comes from).
> 
> But, apparently, what you want is Q_DECL_EXPORT.
> 

Yes, KDE_EXPORT is under windows short for __declspec(dllexport):

#elif defined(_WIN32) || defined(_WIN64)
#define KDE_NO_EXPORT
#define KDE_EXPORT __declspec(dllexport)
#define KDE_IMPORT __declspec(dllimport)
#else

And Q_DECL_EXPORT is the Qt analog:

#ifndef Q_DECL_EXPORT
#  ifdef Q_OS_WIN
#    define Q_DECL_EXPORT __declspec(dllexport)


> And, no, I don't think this is correct at all. There has to be another 
> solution. In Qt3, QCString inherited from QMemArray<char> and there's no 
> such exporting trickery.
> 
> In Qt4, we have very, very similar cases:
> class Q_GUI_EXPORT QPolygon : public QVector<QPoint>
> class Q_GUI_EXPORT QItemSelection : public QList<QItemSelectionRange>
> 

I've tried to reproduce the linker error without success.
(two dlls, one links against the other, template A, a class
which inherits from A, ...)
Maybe there is only one constellation which reproduce it.

But even if I could reproduce it, it only shows that it is a compiler
bug, because I don't see any reason why there must be a linker error.

But I haven't found a bugreport at
http://connect.microsoft.com/VisualStudio/feedback/


So the best we can do is to find a work-around. And this is maybe
the explicit export of the template instantiation.

Peter