KConfig issues prevent compiling KDE applications under Windows

[Albert Astals Cid]

El dijous, 2 de febrer de 2017, a les 12:46:14 CET, Milian Wolff va escriure:
> On Mittwoch, 1. Februar 2017 14:34:37 CET David Faure wrote:
> > 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.
> 
> This is a violation of ODR and thus undefined behavior. Afaik even with
> clang you can hit issues in such situations - I know I've seen this with
> clang on KDevelop.
> 
> > 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.
> 
> That should be done, imo.

Does that mean that:
 A) Distros don't build tests so the private files don't get exported
 B) Distros export private files so they can build tests
 C) Distros have to build things twice, one for running tests and one for 
installing?

Cheers,
  Albert

> 
> Bye