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
