KConfig issues prevent compiling KDE applications under Windows

[David Faure]

On jeudi 2 février 2017 20:03:10 CET Albert Astals Cid wrote:
> 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?

To avoid any confusion, let's not talk about "exporting files", that's unclear.
A class is exported, a file is installed, the two things are orthogonal.

So to clarify, distros have the choice between:

1) building tests, in which case they would end up with a few more exported classes in the lib
(but the private headers are not installed, so no application can exploit this)

2) not building tests, in which case they are not affected by this.


In Qt there is indeed a slightly different system because there is the option to build 
only tests which don't require private symbols, and the option to export the necessary
private symbols (developer-build). I.e. the tests themselves use some #ifdef.
I'm not sure the small increase in the number of exports in case 1 above is worse
yet another cmake option and increase in the combinatory number of cases to check
(#ifdef = we should check both cases).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5