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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
