This is from GIT master. Problem still exists, but I could try disabling unit tests and continue. I hope it gets fixed anyway soon so that other users wouldn't run into the same problem.
On Fri, Feb 3, 2017 at 12:08 AM, Jaroslaw Staniek <stan...@kde.org> wrote: > > > On 1 February 2017 at 14:34, David Faure <fa...@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@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. > > > 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, fa...@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 > -- Best Regards, Jasem Mutlaq
