Reply to topic

Successful build of Krita on Windows with Emerge

User avatar Mike A.
KDE Developer
Posts
41
Karma
0
OS
I took an interest in hacking at Krita and thought I might try getting it to work in Windows. I began by attempting the instructions on this wiki for building Calligra. This is the officially recommended way to build KDE apps on Windows. Naively following the instructions I was not able to get Krita to run, though I got through the process successfully. It was only after a little more research I found Boud's instructions for building Krita. Trying to use Cmake to do all the work of downloading and managing dependencies didn't go very well, but looking through the dependencies helped me figure out what I was missing for building Krita. I decided the best course of action would be to patch up Emerge following the dependencies specified in the Krita build instructions, and I was able to make it work successfully. If you want to hack Krita on Windows I would recommend trying this approach first.

The process is not fully tested yet so if anyone wants to give it a shot let me know if there are hang-ups. Most of the changes are just adding new packages and changing some settings for Emerge, e.g. setting it to download QT 4.8.6 instead of 4.8.5, and adding support for the eigen3 package. These instructions are for building a 64 bit version of Krita.

Necessary and Recommended software
  • Visual Studio 2012 Express with service pack 1 and November CTP update applied.*
  • Git*
  • Python 3.4*
  • Ag, a faster version of Grep
  • Everything, which an awesome instantaneous search
  • SmartGit: No matter how cool you look using the Git command line, it is really a terrible interface.
  • Tee.exe: Writes a log to disk while displaying it on screen. Used as follows: cmake . -options | tee configlog.txt
  • Ninja: Awesome software for quick builds of large projectss. I've only tested it with CMake 3.2.1.
  • CMake 3.2.1: Best for using Ninja. Emerge will install an earlier version of CMake but the newest version works well.

Building Krita on Windows using Emerge:

First, read the instructions for building Calligra on the Wiki. You need to create a directory tree and tell the system where to find your compiler. We'll make a RelWithDebInfo build. Follow the instructions up to the step where we clone Emerge:
Code: Select all
git clone git://anongit.kde.org/emerge.git
cd emerge
git checkout 4.13

Then download and install this patch for the Emerge directory. I believe the command is "git apply Build-Krita-more-easily.patch." (Or use SmartGit!) Continue to follow the instructions for configuring Emerge. I've included a copy of the file kdesettings.bat with settings that worked for me, but you'll need to put in your own directory names. Check the half of the file carefully to make sure everything looks OK. You need to leave the buildtype as x86_amd64 for Visual Studio 2012, which isn't in the official instructions. Once everything is set up, we can run kdeenv.bat - this creates the build environment where we can run emerge.

We'll download everything including the kitchen sink, because HDD space is cheap. Before we start, understand that this is a rocky procedure and after you get through this it's much easier. Here's a little documentation on Emerge. If you know Python you should have no problem tweaking it to work right, it's a brilliant little system. Here goes:
Code: Select all
emerge qt
emerge kdelibs
emerge kde-runtime
emerge boost
emerge ilmbase
emerge tiff
emerge lcms2
emerge eigen2
emerge exiv2
emerge soprano
emerge gsl
emerge libcurl
emerge coreutils
Obviously this will take a while! The first three steps are the longest of all. Qt4 is aging and has a few well-known bugs on Windows, particularly the WebKit subdirectory. Qt5 is much better behaved, so hopefully this will only be temporary. After applying the patch I find Qt only halts with one error. The Qt "moc" code preprocessor creates .cpp files in the build directory
\kde\build\libs\qt-all\work\msvc2012-RelWithDebInfo-4.8.6\src\3rdparty\webkit\Source\WebCore\tmp\moc\release_shared
which contains a chain of ..\..\..\..\..\ which is one too many. I just deleted one of the ..\ from each of the files, and it continued just fine. Perhaps you won't run into this error. I'm not quite sure how to correct this mistake. KDE also takes a while to build but it's more nicely behaved. Everything else is small and quite fast.

We're not done yet though. After emerging coreutils, you'll want to go into /dev-utils/bin and delete link.exe and make.exe, since they can interfere with the Microsoft versions if they're in your system path. The reason we're separating the libraries into two groups is because the second batch gave me a little more trouble. They are working alright on my computer right now after making the changes you pulled from the patch, except for the last one.
Code: Select all
emerge vc
emerge libssh
emerge glew
emerge eigen3
emerge ocio
emerge breakpad
emerge shared-mime-info
A second piece of the puzzle I couldn't fix by patching was shared-mime-info. Instead I just downloaded the binary and added it to a folder in the system path. Let me know if you figure out a way to get it going.
Now that you have a healthy 10 gigabytes of dependencies to feed the Calligra suite it's time for the fun part: compiling Krita! Navigate to to /kde/git and check out the source:
Code: Select all
cd C:/kde/git/
git clone [url]git://anongit.kde.org/calligra.git[/url]
cd ../build
mkdir calligra
cd calligra
cmake -DCMAKE_INSTALL_PREFIX=..\..\ ..\..\git\calligra -DCMAKE_BUILD_TYPE=%EMERGE_BUILDTYPE%  -DPRODUCTSET=KRITA -DKDE4_BUILD_TESTS=OFF -DHAVE_MEMORY_LEAK_TRACKER=OFF -DPACKAGERS_BUILD=ON -DBUILD_doc=OFF -DCMAKE_MODULE_LINKER_FLAGS=/machine:x64 -DCMAKE_EXE_LINKER_FLAGS=/machine:x64 -DCMAKE_SHARED_LINKER_FLAGS=/machine:x64 -DCMAKE_STATIC_LINKER_FLAGS=/machine:x64 -DCMAKE_RC_COMPILER="C:/Program Files (x86)/Windows Kits/8.0/bin/x64/rc.exe" -Wno-dev -G"NMake Makefiles JOM"

Now I'm not sure what all of those cmake commands are for, but I know it makes a working configuration for me! I add a |tee krita_configlog.txt to the end of that to save the log. Then you'll run make/make install:
Code: Select all
jom -j16
jom -j16 install

If you want, you can change "NMake Makefiles JOM" to "Visual Studio 11 Win64" or "Ninja." (You'll have to delete CMakeCache.txt before doing so.) Generating Visual Studio 11 files from CMake allows you to play around with Krita in the IDE. Using Ninja you can change the last two commands to "ninja" and "ninja install" and it will be significantly faster, but the output is less useful, so better to save that for after your first successful build, and you can use it to re-compile. I don't see any reason that Krita shouldn't compile "as-is."
User avatar scottpetrovic
Registered Member
Posts
520
Karma
4
OS
Wow! Thanks for writing this up. This must have taken quite some time to get going and write about. I haven't actually tried to build Krita on a Windows machine ( have done it a few times on linux). I might give it a shot between Boud's instructions and yours. It would be nice to have more people on Windows poking around at it.
User avatar Mike A.
KDE Developer
Posts
41
Karma
0
OS
Yes, once I started poking around it became like a game. You get a cryptic failure message, decipher it, tinker with the code, then make it a little further. (Or more likely it derails at the same point and you keep on tinkering.) The percentage complete turns into your score.

If you do try it let me know, I'm very curious.
User avatar boudewijn
KDE Developer
Posts
4995
Karma
20
OS
Hi Mike!

Good to see you got success with this approach. What I'm wondering about... Does g'mic work reliably for you with this build? If not, I'd be really interested in a build with mingw. I've tried all kinds of approaches, including cross-compiling, but I was getting so strapped for time that I had to give up for now... But for you it should be a simple matter of selecting a different compiler in emerge, right :-)
giblet
Registered Member
Posts
3
Karma
0
Nice, thanks for figuring all that out! I had attempted this a few months ago, but gave up out of frustration about 2/3 of the way through. I am glad you are more patient than I am :)
User avatar scottpetrovic
Registered Member
Posts
520
Karma
4
OS
I have been trotting along ok trying to get this Windows build to work. I am trying the "Boud route" to building so far. I updated the CMake list so it pulls the dependencies (seems like it is working). I hit a snag when trying to build krita though. I am not sure how to decipher these error messages. The best I could find on the Interwebs was it has something to do with a EXE not being found when compiling. I am on Windows 8.1, so maybe file paths changed. What version of Windows are you guys using? This is just part of the message.


"C:\dev\YOURTREE\b\ext_krita.vcxproj" (default target) (1) ->
"C:\dev\YOURTREE\b\ext_eigen3.vcxproj" (default target) (4) ->
(CustomBuild target) ->
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.ta
rgets(172,5): error MSB6006: "cmd.exe" exited with code 9009. [C:\dev\YOURTREE\
b\ext_eigen3.vcxproj]


"C:\dev\YOURTREE\b\ext_krita.vcxproj" (default target) (1) ->
"C:\dev\YOURTREE\b\ext_exiv2.vcxproj" (default target) (6) ->
"C:\dev\YOURTREE\b\ext_expat.vcxproj" (default target) (7) ->
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.ta
rgets(172,5): error MSB6006: "cmd.exe" exited with code 9009. [C:\dev\YOURTREE\
b\ext_expat.vcxproj]


"C:\dev\YOURTREE\b\ext_krita.vcxproj" (default target) (1) ->
"C:\dev\YOURTREE\b\ext_exiv2.vcxproj" (default target) (6) ->
"C:\dev\YOURTREE\b\ext_gettext.vcxproj" (default target) (8) ->
"C:\dev\YOURTREE\b\ext_win_iconv.vcxproj" (default target) (9) ->
iconv.dir\RelWithDebInfo\win_iconv.obj : fatal error LNK1112: module machine
type 'X86' conflicts with target machine type 'x64' [C:\dev\YOURTREE\b\ext_win_
iconv-prefix\src\ext_win_iconv-build\iconv.vcxproj] [C:\dev\YOURTREE\b\ext_win_
iconv.vcxproj]
win_iconv.dir\RelWithDebInfo\win_iconv.obj : fatal error LNK1112: module mach
ine type 'X86' conflicts with target machine type 'x64' [C:\dev\YOURTREE\b\ext_
win_iconv-prefix\src\ext_win_iconv-build\win_iconv.vcxproj] [C:\dev\YOURTREE\b\
ext_win_iconv.vcxproj]
iconv.dir\RelWithDebInfo\win_iconv.obj : fatal error LNK1112: module machine
type 'X86' conflicts with target machine type 'x64' [C:\dev\YOURTREE\b\ext_win_
iconv-prefix\src\ext_win_iconv-build\iconv.vcxproj] [C:\dev\YOURTREE\b\ext_win_
iconv.vcxproj]
win_iconv.dir\RelWithDebInfo\win_iconv.obj : fatal error LNK1112: module mach
ine type 'X86' conflicts with target machine type 'x64' [C:\dev\YOURTREE\b\ext_
win_iconv-prefix\src\ext_win_iconv-build\win_iconv.vcxproj] [C:\dev\YOURTREE\b\
ext_win_iconv.vcxproj]
User avatar boudewijn
KDE Developer
Posts
4995
Karma
20
OS
Hi Scott,

That basically means you've mixed up x64 and x86 builds in one tree. So part of what you built is x86, part is x64. I'm afraid that that means that you basically have to start over. That's what I did when I got this error.
User avatar Mike A.
KDE Developer
Posts
41
Karma
0
OS
boudewijn wrote:Hi Mike!

Good to see you got success with this approach. What I'm wondering about... Does g'mic work reliably for you with this build? If not, I'd be really interested in a build with mingw. I've tried all kinds of approaches, including cross-compiling, but I was getting so strapped for time that I had to give up for now... But for you it should be a simple matter of selecting a different compiler in emerge, right :-)


Hi Boud - g'mic does work reliably, it fails tests and crashes krita every time. I just got a chance to work on Krita this weekend and I just revved up a mingw build as we speak. Wish me luck.

I saw that you posted on your blog about compiling the CMake version of Krita installer. I completely agree with you that cross-platform development needs to be much higher priority for Calligra. However I don't think reverting to CMake is necessarily the way to go. I'm not sure if you've poked at Emerge, but every time I've had a problem I've found that Emerge already offers a way to solve it. The entire thing is written in Python and it's a snap to customize, unlike CMake which runs on 85% voodoo as far as I'm concerned. Emerge calls cmake when necessary but accommodates arbitrary build systems. In fact, I think it could even be pretty straightforward to write an Emerge script which builds only the dependencies you've listed on your blog, inclusive of all the stripped versions, patches, binary installs, aliases and whatever else needs doing.

Switching to the master branch of Emerge (which installs kde5/frameworks) will be another benefit of finishing the Qt5 port. Compared to the 4-13 branch which was committed over two years ago emerge has become much more polished. I checked out the Emerge repo and typed "emerge frameworks" and it installed Qt, KDE and everything without pausing.
User avatar Mike A.
KDE Developer
Posts
41
Karma
0
OS
I thought it might be useful to share some of my build notes here.
Scott: The first one will be helpful for you.

  • To check whether you've got the right version of your libraries: (i.e. debug/release, x86/amd64) you can use
    Code: Select all
     dumpbin xxx.lib /headers

  • Another useful tool for figuring out random library-related crashes is dependency walker. This tells you which .dlls your code is trying to load. It is useful for finding system path contamination (I think I have about 50 versions of libssl32.dll installed by various programs...)
  • One bit of poorly documented configuration space: the files kritarc.txt, kdebugrc.txt, and a few more contain configuration options. If you find you have problems with locating plugins (e.g. "LittleCMS plugin was not found" popup) you can try deleting these files. I think it generally loads the ones in the %AppData%\.kde\ folder though there are several copies on the computer. I also uninstalled the prepackaged Krita to minimize confusion.
  • It really does make a big difference to use Ninja. One thing that can help a "set-and-forget" is the -k option, which tells Ninja to continue a build until accumulating a certain number of errors, instead of stopping after the first error.
    Code: Select all
    ninja -k 100

  • There is a way to tell Emerge to use ninja but it's a bit annoying to figure out. Also VC won't compile with ninja out of the box.
  • Although I'm an Emacs guy Qt Creator has been my IDE of choice. I use it to edit code and then run Ninja on the command line to build, install and run. Qt Creator requires you to pass a list of cmake flags. I went pretty heavy on them for safety's sake. They're all down at the end of this post.
  • Ninja's great as a build tool but has to call cmake to perform the installation. To speed up installs a bit you can replace update-mime-database.exe with nop.exe after everything's up and working right.
  • Now a few problems. First, libfftw was pretty easy to install from binary, just go to http://fftw.org/install/windows.html and follow the instructions.
  • OpenSSL is still a huge pain. Hopefully it can be excised after switching to KDE5.
  • A few of the unit tests added .dll as libraries instead of the .lib files; this creates a cryptic error along the lines of "cannot read target abc.dll." I traced it down to an add_libraries command in CMake. For now I just disable building the particular tests. Hopefully upgrading to CMake 3 later on will fix this.



CMake flags for Qt Creator using MSVC 2012:
Code: Select all
-DKDE4_BUILD_TESTS=OFF
-DCMAKE_INSTALL_PREFIX=E:\kde4
-DCMAKE_BUILD_TYPE=RelWithDebInfo
-DPRODUCTSET=KRITA
-DHAVE_MEMORY_LEAK_TRACKER=OFF
-DPACKAGERS_BUILD=OFF
-DBUILD_doc=OFF
-DCMAKE_CXX_FLAGS="/Gm /MD /Zi"
-DCMAKE_MODULE_LINKER_FLAGS ="/machine:x64"
-DCMAKE_EXE_LINKER_FLAGS="/machine:x64 /LTCG"
-DCMAKE_SHARED_LINKER_FLAGS="/machine:x64"
-DCMAKE_STATIC_LINKER_FLAGS="/machine:x64"
-DCMAKE_RC_COMPILER="C:/Program Files (x86)/Windows Kits/8.0/bin/x64/rc.exe"
User avatar scottpetrovic
Registered Member
Posts
520
Karma
4
OS
thanks for all of your responses. I will spend some time going through these tools and techniques. I am not really a programmer, so these things tend to take me a bit longer to learn and get through. Excited to take this information and give it another go. I will try the emerge route this time with Mike's suggestions.
User avatar Mike A.
KDE Developer
Posts
41
Karma
0
OS
scottpetrovic wrote:thanks for all of your responses. I will spend some time going through these tools and techniques. I am not really a programmer, so these things tend to take me a bit longer to learn and get through. Excited to take this information and give it another go. I will try the emerge route this time with Mike's suggestions.


Let me know if you run into any trouble applying the patch. I've made a few more tweaks since posting the other version. This one separates a few additional changes I made. You should be able to check out kde-4.13 and do it all in Git immediately. https://dl.dropboxusercontent.com/u/160 ... _patch.zip As a reminder, on top of these things that were natural to fix programmatically there were a more tweaks in the Qt build I just did by hand, and I found it was easier to build OpenSSL, LibFFTW and update-mime-database separately. I recommend grabbing update-mime-database since the only thing you need is a working executable... just make sure to put it deep down in your path so you don't accidentally link your programs to the .dlls in the archive.
https://dl.dropboxusercontent.com/u/160 ... _patch.zip
https://dl.dropboxusercontent.com/u/160 ... atabase.7z


Krita itself was pretty straightforward to attack after wrestling through Emerge. I can share a patch for that too, it probably won't fix much more than the handful of issues I kept in my notes:
1) The things I wrote down were that the very first line of \krita\cmakelists.txt needed to have the command "add_definitions" switched to "add_compiler_options",
2) vcmacros.cmake generated some cl.exe command lines for kritaimage.dll that were too long and I had to insert a few @<< into the makefile*
3) The einspline\nugrid.cpp needed to have the namespace boost::math:: written explicitly in front of the functions expm1 and log1p
4) I needed to comment out SetProcessDPIAware() in main.cc.

*Another nice thing about Ninja is that it stacks the entire build command system into one file build.ninja, so whenever something goes wrong it's easy to locate the commands giving rise to the error, and it's easy enough to read that you can make small tweaks on the spot.
rajeshpal
Registered Member
Posts
2
Karma
0
I am not able to build on Windows 8.


c:\kderoot\emerge>kdeenv.bat
kdesettings.bat executed
KDEROOT : c:\kderoot
KDECOMPILER : msvc2013
KDESVNDIR : c:\kderoot\svn
KDEGITDIR : c:\kderoot\git
DOWNLOADDIR : c:\kderoot\download
The system cannot find the path specified.
c:\kderoot>
c:\kderoot>emerge qt
emerge debug: buildAction: all
emerge debug: packageName: qt
emerge debug: buildType: RelWithDebInfo
emerge debug: buildTests: False
_____________________________________________________________
User avatar Mike A.
KDE Developer
Posts
41
Karma
0
OS
I understand. The last post is already a little bit outdated. Can you share more information?

I suggest you try to build Krita with Qt5. The Emerge system is working much better on the latest branch than on older versions. Right now Krita on Frameworks is not ready to be used as a painting program, but there is no shortage of opportunity to fix changes and help complete the port. The Windows version comes out very close to the Linux version.

Another change is that I recommend you use the Powershell version. Just run kdeenv.ps1. Powershell is a much saner environment in Windows and can be greatly enhanced with PSReadLine.

This is by no means a "set it and forget it" build. You'll have to go in and try to fix errors, and if you come up with generalized solutions, push them as a patch. Hopefully these will be things that can be pushed to the master branch.


Apply this patch to the "master" branch of Emerge. The goal is to make this patch smaller over time and contribute it upstream.
https://dl.dropboxusercontent.com/u/160 ... erge.patch


emerge qt
emerge pkg-config
emerge boost

Make sure that you get Qt 5.5, earlier versions are very buggy. For now, you will emerge the necessary KDE frameworks one at a time. This will pull various things from Git. Most tests will not compile, so comment out tests folder from the cmakelists of KDecoration, kdelibs4support and Kross and "demo" in Oxygen. There is a nasty problem with KDocTools involving a CMake routine for encoding invoking a Perl script. The problem is that it replaces colons, e.g. c:\ will become c%3A\, and I do not know how to fix it except to remove the method entirely. There are probably other issues not covered by the patch.

emerge karchive
emerge kcodecs
emerge kconfig
emerge kcoreaddons
emerge kguiaddons
emerge ki18n
emerge kitemmodels
emerge kitemviews
emerge kwidgetsaddons
emerge threadweaver
emerge kcompletion
emerge kiconthemes
emerge sonnet
emerge kparts
emerge kio
emerge kxmlgui
emerge kross
emerge kwallet
emerge kglobalaccel
emerge kemoticons
emerge kconfigwidgets
emerge kdewin-lib
emerge kdelibs4support
emerge kross


This is very cutting edge, so good luck.
Stefano Bonicatti
KDE Developer
Posts
16
Karma
0
OS
So it's time i pass here too to ask help.
I've managed to compile Krita not with Emerge but with CMake, starting from boud kritadepwin project (and updating it).
Now though i'm in a weird situation where starting Krita manually works fine, but through QtCreator it cannot load the plugins:

krita(1108)/koffice (lib komain) void __cdecl KoPluginLoader::load(const class QString &,const class QString &,const struct KoPluginLoader::PluginsConfig &,class QObject *): Loading plugin "LCMS Color Management Engine for Pigment" failed, "Cannot load library C:/ActiveProjects/Krita/i/lib/kde4/kolcmsengine.dll: The specified module could not be found."
krita(1108)/koffice (lib komain) void __cdecl KoPluginLoader::load(const class QString &,const class QString &,const struct KoPluginLoader::PluginsConfig &,class QObject *): Loading plugin "Lut Docker" failed, "Cannot load library C:/ActiveProjects/Krita/i/lib/kde4/kritalutdocker.dll: The specified module could not be found."


The funny thing is that THEY ARE THERE!
Also i had the icons not loading but apparently setting KDEDIRS pointing to the install directory and KDEHOME to %APPDATA%\.krita made it work (note, again launching Krita manually worked fine).

So i really don't know where to bash my head anymore, i have half Windows in the PATH directory, included those plugins dll (which shouldn't be needed).. and i really don't get what QtCreator is doing to make Krita not find those plugins.

PS: Ok apparently writing this down made me really think the last things i didn't tried: ProcessMonitor by SysInternals..
With this i've found that it's not kolcmsengine.dll that is not finding but a dependency, namely lcms2.dll.. which it was searching in the current working directory.. set by QtCreator, which though pointed to a build folder instead of the install one, where the dll was present.
Antton T.
Registered Member
Posts
3
Karma
0
I've been working on MinGW fixes for all the dependencies. I've documented the process so far in the kde-windows mailing list (archived here and here). I probably could have saved some time had I looked into your patch a bit earlier :). Great job there. However, I got things to compile with far fewer changes than what you've listed there, and I'd like to avoid unnecessary modifications, so I'm wondering about the reasons behind some of them. It might be a good idea to add some commentary to the patch explaining why each modification is made, so that new people can get up to speed more quickly. Might be a bit too laborious to do after the fact, of course.

Your latest listing is missing:
emerge eigen3
emerge lcms2
emerge exiv2

Exiv2 0.25 gives a linker error with mingw, but this can be fixed by adding TARGET_LINK_LIBRARIES( exiv2lib ws2_32 ) to the mingw section of exiv cmakelists.

About the issues mentioned:
If I got it right, when building kross, the metafunction doesn't get built into the krosscore dll (at least with mingw) so the test will also fail. Just disabling the test might cause some problems later on. I posted a quick fix to the mailing list thread. Tests for KDecoration and kdelibs4support build fine for me without modification.

The KDocTools issue can be patched by adding colon character to the list of escaped characters in download\git\kdoctools\cmake\uriencode.cmake (assuming you are talking about the same thing). I ran into the same issue with kdelibs4support install script, and the same amendment worked there too.

About building krita:
I just got started with this yesterday. I'm assuming frameworks is the right branch to use for now (soon to be merged to master, apparently). I set jom to log and ignore errors, and did a full build. I got some "not declared in this scope" errors and missing include paths in few places. Nothing too major at first glance, although kritacolor seems oddly broken or unfinished(?), and apparently nothing depends on it(?).

Can Krita be successfully compiled with MSVC at the current state?
Stefano: You're compiling the pre-frameworks version, right? I'm getting a bit confused by all the variations we're dealing with here :).

 
Reply to topic

Bookmarks



Who is online

Registered users: Baidu [Spider], Bing [Bot], gfielding, Google [Bot], ipwizard, irfanhilmi, jmacleod, robertrathbone