KConfig issues prevent compiling KDE applications under Windows

[Jaroslaw Staniek]

On 1 February 2017 at 14:34, David Faure <faure at kde.org> 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 <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.


Hi,
Apparently it is since eab822e20620 (Jan 15).
​The bug #​375654 does not seem to provide version info but the fix isn't
just released, right? CC'd Stephen Kelly.

I don't see much to blame MSVS for here, even the message is rather clear:
the binary being linked (not compiled) already contains the symbol.
I'd avoid hacks such as (kconfig/autotests/CMakeLists.txt):

set(kentrymaptest_SRCS kentrymaptest.cpp ../src/core/kconfigdata.cpp)

Now since eab822e20620 the class is exported and all the other symbols are
inline so the hack isn't needed. Anyone, feel free make a general fix.

PS: The topic isn't linker-dependent, just the Microsoft's linker
demonstrated consequences of the hack.
Going further for quality, exporting just for test is suboptimal so it's a
good practice to export only for tests this way by using special macros:

Calligra for many years: https://api.kde.org/bundled-ap
ps-api/calligra-apidocs/libs/main/html/komain__export_8h_source.html

KDb: https://cgit.kde.org/kdb.git/tree/src/config-kdb.h.cmake#n43

I'd recommend this not just for frameworks (or do we have this in ECM
already?).
Obviously CMake's generate_export_header() does not support it but IMHO it
would.
Then the extra cmake conditions would not be needed.

​So maybe that would be even better fix for KConfigData tests.​



> 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_expo
> rt.h
> for an example.
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>


-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20170202/bbaf45bc/attachment.html>