Continuing from previous listing:
12. kdelibs4support fails with several conflicting declarations errors.
First one as an example:
r:/include/mingw/time.h:32:76: error: conflicting declaration of 'tm*
localtime_r(const time_t*, tm*)' with 'C' linkage
KDEWIN_EXPORT struct tm *localtime_r(const time_t *clock, struct tm
*result);
r:/mingw64/x86_64-w64-mingw32/include/time.h:269:34: note: previous
declaration with 'C++' linkage
__forceinline struct tm *__cdecl localtime_r(const time_t *_Time, struct
tm *_Tm) {
^
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.
13. boost-iostreams fails with:
error: at
R:/build/win32libs/boost-headers/work/boost_1_58_0/tools/build/src/kernel\modules.jam:107
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'
error: Tried to build the target twice, with property sets having
error: these incompatible properties:
error:
error: - none
error: - <address-model>64 <architecture>x86 <deduced-address-model>64
<deduced-architecture>x86
error:
error: Please make sure to have consistent requirements for these
error: properties everywhere in your project, especially for install
error: targets.
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.
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.
_______________
*3)
lib boost_iostreams
: $(sources)
: <link>shared:<define>BOOST_IOSTREAMS_DYN_LINK=1
<define>BOOST_IOSTREAMS_USE_DEPRECATED
[ ac.check-library /zlib//zlib : <library>/zlib//zlib
<source>zlib.cpp <source>gzip.cpp ]
: <address-model>64
<architecture>x86
: <link>shared:<define>BOOST_IOSTREAMS_DYN_LINK=1
;
[5]
http://stackoverflow.com/questions/28398390/boost-build-breaks-name-clash-for-pstage-liblibboost-system-so-1-58-0
On Thu, Aug 6, 2015 at 11:10 PM, Antton Tapani <antton.tap...@gmail.com>
wrote:
> 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.
>
> More about kross:
> 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:
> https://dl.dropboxusercontent.com/u/95677592/kde/metafnpatch.diff
>
> 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.
>
>
>
> On Wed, Aug 5, 2015 at 1:49 PM, Michael Abrahams <miabr...@gmail.com>
> wrote:
>
>> Hello Anton:
>>
>> I saw your post in the Krita forums. I already posted a short reply
>> to you there, I just recently noticed this list.
>>
>> https://forum.kde.org/viewtopic.php?f=281&t=125861
>>
>> For anyone else who has not seen that thread: I have been working on a
>> large set of updates to Emerge, but sorting the ad-hoc alterations
>> from the true solutions is a large amount of work. If anyone is
>> interested in inspecting the large patch I have posted and helping me
>> carve it up into smaller pieces I would be very grateful.
>>
>> There are many issues with Emerge using both MSVC and MinGW. Now that
>> Sourceforge is stabilized, it should be possible to solidify
>> everything again. Right now I would recommend starting with MSVC
>> 2013. One of the issues with MinGW right now is that not only do you
>> have to port packages to Windows, but you may also have to port from
>> GCC4 to GCC5, since MSYS just switched. For example the GPG error you
>> posted is caused by this bug, which was not yet ported to the CMake
>> version of the buildfile in Emerge.
>> https://lists.gnutls.org/pipermail/gnupg-devel/2015-March/029588.html
>> (The solution is to add an extra -P in the CMakeLists.txt as described
>> above.)
>>
>> I also recommend you avoid trying to build Frameworks components you
>> do not need for the time being. KDEWebkit is not used in Krita, so
>> luckily you do not have to solve this bug to get what you need out of
>> Emerge.
>>
>> Finally I would like to suggest you give Powershell another try. Like
>> Zsh, it is a full-featured shell that just needs some tweaking to get
>> set up. (Look into Posh-Git and PSReadLine. You can also type "dir
>> alias:" to see a list of cmd- and posix-inspired shortcuts to the
>> shell commands.)
>>
>> Michael Abrahams
>> _______________________________________________
>> Kde-windows mailing list
>> Kde-windows@kde.org
>> https://mail.kde.org/mailman/listinfo/kde-windows
>>
>
>
_______________________________________________
Kde-windows mailing list
Kde-windows@kde.org
https://mail.kde.org/mailman/listinfo/kde-windows
