On mardi 31 janvier 2017 07:58:15 CET Jasem Mutlaq wrote: > Hello, > > KConfig used to work perfectly fine under Windows. I recently tried to > compile KStars under Windows 10 (64bit) with MSVC 2015 and Qt 5.8 using > Craft, but encountered an issue as explained in this bug report: > > https://bugs.kde.org/show_bug.cgi?id=375654 > > I talked with Craft maintainers (Hannah et al) and they told me this was an > issue from KConfig side, not Craft. Can someone please look into this and > fix it as it our release is dependent on this.
KF5ConfigCore.lib(KF5ConfigCore.dll) : error LNK2005: "public: class QMap<struct KEntryKey,struct KEntry>::iterator __cdecl KEntryMap::findEntry(class QByteArray const &,class QByteArray const &,class QFlags<enum KEntryMap::SearchFlag>)" (?findEntry@KEntryMap@@QEAA?AVite rator@?$QMap@UKEntryKey@@UKEntry@@@@AEBVQByteArray@@0V? $QFlags@W4SearchFlag@KEntryMap@@@@@Z) already defined in kconfigdata.cpp.obj Thanks MSVC for a very readable error message as always ;) One note though: this is a failure to link a unittest, your release isn't blocked, you can just disable the building of unittests in kconfig. The double definition can be explained, the unittest links to KF5ConfigCore and then also compiles in ../src/core/kconfigdata.cpp because that class is not exported. This is something we do in quite a number of other places too, always for autotests. kde-windows people, if you confirm there is no way to make this work (some linker flag maybe?), then I do see one solution: the one used by Qt (and konqueror), which is an export macro that only exports the class when compilation of autotests is enabled. See konqueror/src/konqprivate_export.h for an example. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
