<div dir="ltr">Continuing from previous listing:<br><br>12. kdelibs4support fails with several conflicting declarations errors. First one as an example:<br>r:/include/mingw/time.h:32:76: error: conflicting declaration of 'tm* localtime_r(const time_t*, tm*)' with 'C' linkage<br> KDEWIN_EXPORT struct tm *localtime_r(const time_t *clock, struct tm *result);<br><br>r:/mingw64/x86_64-w64-mingw32/include/time.h:269:34: note: previous declaration with 'C++' linkage<br> __forceinline struct tm *__cdecl localtime_r(const time_t *_Time, struct tm *_Tm) {<br> ^<br>This is similar or possibly the exact same error that I got with khtml at point 10 (future people, see archives), which I glossed over quite illegitimately. Looking at the headers, these seem to be mutually exclusive, but for whatever reason the include/mingw one doesn't get properly disabled if _POSIX_THREAD_SAFE_FUNCTIONS is defined and the other definitions are in effect. I wrapped the include/mingw ones inside "#ifndef _POSIX_THREAD_SAFE_FUNCTIONS" and it compiles fine.<br><br>13. boost-iostreams fails with:<br>error: at R:/build/win32libs/boost-headers/work/boost_1_58_0/tools/build/src/kernel\modules.jam:107<br>error: Name clash for '<pr:\build\win32libs\boost-iostreams\work\mingw-w64-RelWithDebInfo-1_58_0\boost\bin.v2\standalone\ac\gcc-mingw-5.1.0\release\threading-multi>zlib.h.o'<br>error: Tried to build the target twice, with property sets having<br>error: these incompatible properties:<br>error:<br>error: - none<br>error: - <address-model>64 <architecture>x86 <deduced-address-model>64 <deduced-architecture>x86<br>error:<br>error: Please make sure to have consistent requirements for these<br>error: properties everywhere in your project, especially for install<br>error: targets.<br><br>Suggested fix is to add "address-model=64 architecture=x86" flags into the bjam call [5] (not the same error, but applicable). I couldn't figure out how emerge produces the bjam call, so instead I added the parameters to build\win32libs\boost-headers\work\boost_1_58_0\libs\iostreams\build\Jamfile.v2 like in *3). Emerge doesn't wipe the boost-headers folder before building, so that should be enough for a quick hack.<br><br>I think I have now built all the dependencies, so I'm soon going to proceed to building Krita. After that I'll repeat the whole thing and produce some proper patches in a less haphazard manner.<br>_______________<br>*3)<br>lib boost_iostreams <br> : $(sources) <br> : <link>shared:<define>BOOST_IOSTREAMS_DYN_LINK=1 <br> <define>BOOST_IOSTREAMS_USE_DEPRECATED<br> [ ac.check-library /zlib//zlib : <library>/zlib//zlib<br> <source>zlib.cpp <source>gzip.cpp ]<br> : <address-model>64<br> <architecture>x86<br> : <link>shared:<define>BOOST_IOSTREAMS_DYN_LINK=1<br> ;<br><br>[5] <a href="http://stackoverflow.com/questions/28398390/boost-build-breaks-name-clash-for-pstage-liblibboost-system-so-1-58-0">http://stackoverflow.com/questions/28398390/boost-build-breaks-name-clash-for-pstage-liblibboost-system-so-1-58-0</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 11:10 PM, Antton Tapani <span dir="ltr"><<a href="mailto:antton.tapani@gmail.com" target="_blank">antton.tapani@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey. I have not posted anything to the Krita forums, as far as I know. Or maybe I've forgotten, which tends to happen. It's Antton btw (double t), in case someone has a similar name. As may be apparent, I'm doing this rather haphazardly at the moment due to lack of time. I've been building everything because I don't know what the Krita dependencies actually are :). Thanks for the listing. MinGW is essential for my purposes, so that's what I'm going with, whether it's currently a good idea or not. Maybe in the process I can contribute to making it work properly.<br><br>More about kross:<br>I think I found the culprit yesterday. The metafunction simply isn't getting compiled into the krosscore dll, so the test obviously cannot link to it. I included metafunction.h in manager.h, and now it at least compiles fine. Ad hoc Patch:<br><a href="https://dl.dropboxusercontent.com/u/95677592/kde/metafnpatch.diff" target="_blank">https://dl.dropboxusercontent.com/u/95677592/kde/metafnpatch.diff</a> <br><br>I don't quite understand how it is even supposed to work without this. It doesn't seem like any of the source files depend on metafunction.h (apart from the test), so it would seem logical to omit it from the dll. Is cmake supposed to do some magic to make sure it's included? Metafunction is mentioned in the core's CMakeLists, but after that, it seems to be mostly forgotten.<div><div class="h5"><br><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 5, 2015 at 1:49 PM, Michael Abrahams <span dir="ltr"><<a href="mailto:miabraha@gmail.com" target="_blank">miabraha@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Anton:<br>
<br>
I saw your post in the Krita forums. I already posted a short reply<br>
to you there, I just recently noticed this list.<br>
<br>
<a href="https://forum.kde.org/viewtopic.php?f=281&t=125861" rel="noreferrer" target="_blank">https://forum.kde.org/viewtopic.php?f=281&t=125861</a><br>
<br>
For anyone else who has not seen that thread: I have been working on a<br>
large set of updates to Emerge, but sorting the ad-hoc alterations<br>
from the true solutions is a large amount of work. If anyone is<br>
interested in inspecting the large patch I have posted and helping me<br>
carve it up into smaller pieces I would be very grateful.<br>
<br>
There are many issues with Emerge using both MSVC and MinGW. Now that<br>
Sourceforge is stabilized, it should be possible to solidify<br>
everything again. Right now I would recommend starting with MSVC<br>
2013. One of the issues with MinGW right now is that not only do you<br>
have to port packages to Windows, but you may also have to port from<br>
GCC4 to GCC5, since MSYS just switched. For example the GPG error you<br>
posted is caused by this bug, which was not yet ported to the CMake<br>
version of the buildfile in Emerge.<br>
<a href="https://lists.gnutls.org/pipermail/gnupg-devel/2015-March/029588.html" rel="noreferrer" target="_blank">https://lists.gnutls.org/pipermail/gnupg-devel/2015-March/029588.html</a><br>
(The solution is to add an extra -P in the CMakeLists.txt as described<br>
above.)<br>
<br>
I also recommend you avoid trying to build Frameworks components you<br>
do not need for the time being. KDEWebkit is not used in Krita, so<br>
luckily you do not have to solve this bug to get what you need out of<br>
Emerge.<br>
<br>
Finally I would like to suggest you give Powershell another try. Like<br>
Zsh, it is a full-featured shell that just needs some tweaking to get<br>
set up. (Look into Posh-Git and PSReadLine. You can also type "dir<br>
alias:" to see a list of cmd- and posix-inspired shortcuts to the<br>
shell commands.)<br>
<span><font color="#888888"><br>
Michael Abrahams<br>
</font></span><div><div>_______________________________________________<br>
Kde-windows mailing list<br>
<a href="mailto:Kde-windows@kde.org" target="_blank">Kde-windows@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-windows" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-windows</a><br>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>