KConfig issues prevent compiling KDE applications under Windows

[David Faure]

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 at KEntryMap@@QEAA?AVite
rator@?$QMap at UKEntryKey@@UKEntry@@@@AEBVQByteArray@@0V?
$QFlags at 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, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5