Home | Content | Search | Navigation | Personal tools | Actions

Building Evolution on Windows

From Evolution

Note that this page is about building Evolution for Windows from sources. If you just want to run Evolution on Windows, there are Windows Installer packages available.

Evolution can be installed in a path containing any Unicode characters, and also works even if the username contains whatever random Unicode characters.

This page is partly based on a message sent by Owen Taylor to the gtk-devel-list in January 2005, based on his experience in setting up a build environment for GTK+ and Pango on Windows from scratch. It was later further edited by TorLillqvist and to the gimpwin-users list.

Thus some parts of this page might talk about things from a perspective of somebody who wants to build GTK+, Pango or GIMP from sources. This will be fixed eventually.

Contents

[edit]

Prerequisites

(When it says "Evolution", that includes also Evolution Data Server.)

To build Evolution on Windows (or cross-compiling from Linux, or Interix) you will first need to set up a development environment. The compiler that must be used is gcc. The combination of gcc for Windows, GNU binutils, and free headers and import libraries for the Win32 API and Microsoft C library is better known as MinGW.

You will also need headers and import libraries for all the software that Evolution depends on. If you want, you can build also those yourself. Especially in the GNOME platform and desktop libraries that only recently have been ported to Windows there certainly are still many things to fix. But if you want to concentrate on just Evolution, it's easiest to install prebuilt packages for the dependencies.

[edit]

Why not MSVC?

Due to some deep technical issues in the CORBA implementation (ORBit2), currently only gcc and especially the GNU linker can be used on Windows to build ORBit2 and software that uses ORBit2. This includes the GNOME platform libraries and Evolution itself.

There has however been some recent reports that this isn't after all so any more with current Microsoft compilers. More investigation is needed. It would indeed be great if Evolution and the stack below could be built with Microsoft's compilers. That hopefully would make it easier for Windows-based developers used to Visual Studio to take part in the development.

[edit]

GCC--MSVC compatibility

The GTK+ libraries and its dependencies (Pango, atk, cairo, GLib) can be built with MSVC. Binaries produced from C source code by gcc and MSVC are compatible. You can call a gcc-built DLL from MSVC-built code and vice versa. There are no problems, as long as you take two issues into consideration:

  • If the API uses structs with certain kinds of bitfields, you must use the flag -mms-bitfields in gcc for the struct field packing to be identical to that MSVC uses. GTK+ uses such API, and the commonly used GTK+ binaries built by TorLillqvist are compiled using gcc with this flag. They are thus also usable from MSVC code, and when building GTK+-using software with gcc, the flag must also be used.

Note that this applies to C code only. For code using C++ APIs, it's impossible to mix compilers. This is intentional not a bug.

[edit]

MinGW

Mingw is the GNU toolchain (gcc, binutils, gdb) targetted for Windows. MinGW does not provide any form of Unix emulation for the programs being built with it. The C library MinGW-built programs use is the Microsoft C library that is bundled with Windows, MSVCRT.DLL. Note that some degree of Unixish APIs are present in this library, however, in addition to the bare ANSI C (C89) features. This is API like open(), read(), write(), for instance. MinGW does provide some random additional Unixness in its headers, like an <unistd.h> header, and an implementation of the <dirent.h> API. But there certainly is no fork() there, no flock(), no <pwd.h> or <grp.h>, no getuid() etc. Also note that due to fundamental differences between Windows and Unix, some Unix functions like chown() or access(), although present, don't really map very well onto Windows functionality.

Get MinGW from www.mingw.org. Navigate to the download page, and download the current versions of GCC, MSYS Developer Toolkit, MSYS, MinGW Runtime, MinGW Utilities, Win32 API, binutils and gdb. Download either the installers (.exe files) or the tarballs. (Don't download the source tarballs unless you are interested) Install (untar) these in some suitable locations. The default locations are c:\mingw for MinGW and c:\msys\1.0 for MSYS, but feel free to use other pathnames. It is best, however, to avoid paths with spaces in the name. Also, don't mix MSYS and MinGW together. (TorLillqvist uses c:\opt\mingw and c:\opt\msys\1.0.)

Try to keep the above tools, other relevant tools and libraries, and the sources you will work on on just one drive letter. Use junctions or mounts if you want to make it appear that all are on the same drive letter even if they in fact are on different volumes.

(Dynamic disks and mounted volumes are a cool way to get Unix-style volume management and mounts in Windows XP. TorLillqvist has dynamic disks "opt" and "devel" which are on different physical disks than C:, but are mounted as c:\opt and c:\devel, for instance. If dynamic disks or mounted volumes on Windows don't mean anything to you, just ignore this paragraph.)

[edit]

Win32 API documentation

You can read Microsoft developer documentation on MSDN. It is faster, though, to have the documentation locally. Install the Platform SDK (which has now been renamed to "Windows SDK"). It contains the same documentation as MSDN.

[edit]

Test MinGW

Once you have MinGW installed, test it by compiling and running a simple Hello World program. Next, use the following to test the Win32 api for MinGW. Save the following as hello.c

// file: hello.c
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
MessageBox(NULL,"Hello World!","Note",MB_OK);
return 0;
}

And then compile with the following command:

gcc hello.c -o hello.exe
[edit]

MSYS

MSYS is a Unix emulation layer whose purpose is to make a Unix shell available for interactive work, and provide the tools used to run configuration scripts and builds. These tools includes sh, make, sed and perl.

MSYS is technically a fork of Cygwin, but unlike Cygwin, it is not intended to be used as a target for development and running own programs. I.e., even if you use MSYS's Unix emulation during development, the programs you build don't have anything to do with MSYS. The risk when using Cygwin and its gcc but with the -mno-cygwin flag is that it is easy to unintentionally drag in Cygwin versions of headers or libraries. gcc -mno-cygwin is not a proper cross-compilation environment from Cygwin to Win32.

The innovative feature in MSYS is that when you pass a MSYS (Unix-style) pathname as command-line argument to a normal Win32 program (i.e. anything except the programs included with MSYS) from the MSYS shell, the pathname is automatically translated into the corresponding Win32 form before actually being passed to the program. This is done through heuristics, and can occasionally go wrong, so that MSYS thinks a command-line parameter is a MSYS path and converts it to the corresponding Win32 pathname when spawning the program, even though it isn't.

During MSYS installation, you'll be prompted for where you installed mingw.

A shortcut to MSYS will be created on your desktop, that launches the MSYS shell in a terminal window. Presumably you will do your work in such a shell window. You can edit etc/profile in MSYS's installation directory to set up PATH, PKG_CONFIG_PATH, BONOBO_ACTIVATION_PATH, etc. Or you can do it in the Control Panel. TorLillqvist has a set of functions in etc/profile that sets up PATH in alternative ways to run against different installed versions of GTK+.

It is a good idea to hide the rxvt.exe in the MSYS bin directory, so that the MSYS shell uses a normal console window. (For instance, rename it to rxvt.nope.exe.) rxvt is said to behave oddly at times, and isn't what end-users have anyway, so using it can be misleading.

To avoid having to refer to folders outside the MSYS hierarchy with a drive letter like /c/opt/misc, it's a good idea to "mount" them in MSYS. (These "mounts" should not be confused with Windows mounts of volumes, or real Unix mounts. MSYS mounts are most like symbolic links or whatever, but implemented through a table in a file.) Edit /etc/fstab in MSYS (i.e., c:\opt\msys\1.0\etc\fstab as a real Win32 path), and add a line like

c:/opt    /opt

Ditto for other top-level folders on the C: drive that you need to refer to often. This also has the benefit that there is less risk of confusion between Win32 pathnames and MSYS pathnames, "/opt/misc" will work both as in MSYS and as a native Win32 path.

[edit]

libtool-cache

Running libtool is very slow on Windows. It really can make a grown man cry. Substantial speedup can be achieved by using libtool-cache by Robert Ögren. Install it and run libtoolcacheize each time after running autogen.sh (or configure).

[edit]

Avoiding relinking in libtool

This is optional. TorLillqvist always edits the line in ltmain.sh that says need_relink=yes to need_relink=no . This speeds up the "install" phase as no relinking needs to be done. It might also have other benefits, I don't remember. It might also be that it means you should run "make install" with PATH containing .libs . Sorry for being so vague, this is something you don't really want to experiment with much once you have it working.

If you decide to try to avoid relinking, too, you need to edit the ltmain.sh in its installed location (/opt/gnuwin32/share/libtool/ltmain.sh for instance) in the case of building modules from SVN. (Needed once only, of course.)

In the case of building something from a tarball, edit the ltmain.sh that came from the tarball, as that is what running the configure script will use.

[edit]

3rd-party prebuilt software

[edit]

gnuwin32

From gnuwin32, download the "Binaries" and "Developer Files" for the following (the version current as of this writing in parens):

  • LibPng (1.2.8)
  • Jpeg (6b)
  • LibTiff (3.7.1)
  • LibTool (1.5.8) (the MSYS version is too old)
  • File (4.13) (needed by LibTool, or actually, is it?)
  • FreeType (2.1.8)
  • RegEx-Spencer (3.8)
  • Bison, including its "dependencies" zipfile (with just two DLLs)
  • Flex

Unpack these in a place of their own. TorLillqvist uses c:\opt\gnuwin32. I find it easier to download the zipfiles and unpack them, instead of downloading the executable installers and running them. The installers are more tedious to use, as they ask you whether you want to create Start Menu entries etc. Having a Start Menu subfolder for things like the JPEG library that just contains an Uninstall entry seems pretty silly to me.

Unzip them all in the same folder. The end result should be that you under c:\opt\gnuwin32 (or whatever location you choose) will have subfolders bin, contrib, include, lib, man, manifest and share.

Unfortunately in the newest version, 3.8g3, the gnuwin32 project has changed the name of the DLL provided by the RegEx-Spencer package from regex.dll to rxspencer.dll. regex.dll is now provided in their ReEx-GNU package, and they are incompatible, but the incompatibility shows up only at run-time, causing a crash.

Copy the bin\regex.dll to bin\rxspencer.dll, as that is what the magic1.dll used by file.exe expects. The GnuWin32 packages sometimes have inter-package DLL name inconsistencies like this.

A manual fixup is needed for libtool. edit bin\libtoolize and change the line that sets prefix=<default location> to prefix=c:/opt/gnuwin32 (or whatever installation location you used).

Also, lib\pkgconfig\libpng13.pc needs to be fixed. Edit it and change all instances of '12' to '13'. Remove the other stuff on the Libs line after -lpng13.

(The GnuWin32 people apparently somehow broke binary compatibility between libpng-1.2.7 and libpng-1.2.8 and thus are being incompatible with the rest of the world and advertising a 'libpng13'. It's only used internally to the png-loader in GTK+, so we can accept that under protest.)

A manual fix is also needed for the bin\freetype-config script. It prints some really silly crap with --libs. Remove the extra junk from the assignment to libs, leaving just libs="-lfreetype".

[edit]

zlib

From the zlib home page, download the official Win32 binaries for zlib. Unzip in a temporary place, and move the DLLs, headers and import libraries into the proper places in some prefix. (DLLs into bin, headers into include, import libraries into lib.) TorLillqvist uses c:\opt\misc for miscellaneous stuff that isn't from GNU nor ported by the gnuwin32 project.

There isn't a .a format import library included, so you will have to create one yourself:

cd /opt/misc/bin
pexports zlib1.dll >zlib1.def
dlltool --input-def zlib1.def --output-lib ../lib/libz.a
rm zlib1.def
[edit]

libxml2

The official port of libxml2 to Windows is available from the Igor Zlatkovic's site. Unzip the libxml2 and libxslt zipfiles either in a separate location (for instance c:\opt\libxml) or in the same place where you put zlib (c:\opt\misc).

Unfortunately Igor Zlatkovic doesn't package any libxml-2.0.pc file. You will have to create one yourself, but it isn't hard.

Building libxml2 with autotools puts the headers in <prefix>/libxml2/libxml/*.h; Zlatkovic's build is having them in <prefix>/libxml/*.h. In this case, the libxml-2.0.pc file should look like this:

prefix=/ignore
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: libXML
Version: 2.6.22
Description: libXML library version 2.
Requires:
Libs: -L${libdir} -lxml2  -lz
Cflags: -I${includedir}

(Replace 2.6.22 with the version of libxml2 you downloaded.) Put that libxml-2.0.pc file in <top>\lib\pkgconfig, where <top> is where you unzipped the libxml2 zipfile.

You will also need to produce a .a format import library for libxml2.dll. Use pexports and dlltool, as for zlib:

cd /opt/libxml/bin
pexports libxml2.dll >libxml2.def
dlltool --input-def libxml2.def --output-lib ../lib/libxml2.a
rm libxml2.def
[edit]

gettext

There are unfortunately several ports of gettext to Win32 floating around. The gettext sources include makefiles for MSVC, which presumably should thus be considered the officially sanctioned way to build gettext. Building using those makefiles produce a DLL called intl.dll. This is what all the GTK+ and GNOME binaries use. gettext packages built with MSVC are available from the GIMP website. Another build of gettext is available from the gnuwin32, but that is not recommended.

[edit]

libiconv

As for libiconv, there are several different builds (mainly using different names for the DLL) available. The officially sanctioned way to build libiconv on Windows is with MSVC, producing iconv.dll. Such a package is available from the GIMP website.

[edit]

popt

Many of the GNOME platform libraries still use the popt library to do command-line parsing. Hopefully during the next development cycle popt will be dropped and GLib's GOption functionality used instead. Until then, you will need a Win32 port of libpopt. The port by TorLillqvist is at http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/.

[edit]

Mozilla NSPR and NSS

Mozilla NSPR and NSS developer packages can be found on ftp.mozilla.org. I guess any relative recent version should work. The Mozilla stuff I use is originally from the Mozilla website, but are also available in slightly repackaged (with mingw import libraries added, for instance and reorganized layout) from http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/ .

I use NSPR 4.6 and NSS 3.10.

[edit]

Perl for intltool

The Perl in MSYS doesn't include the XML::Parser module. The intltool commands require that module. It's easiest to use ActiveState's Perl (I use version 5.6.1, but newer versions work fine, too). Set the environment variable INTLTOOL_PERL=/path/to/activeperl/bin/perl.

[edit]

pthread

Evolution uses the POSIX thread API heavily. I first considered changing it to use GLib's GThread API instead, but decided it's easier to just use the pthreads-win32 implementation of the POSIX thread API for Win32. (It uses exactly the same underlying Win32 thread API as GThread does, of course, so there aren't any issues of imcompatibility etc.)

I use the 2.7.0 version, which was the latest as of this writing. A prebuilt package of it can be downloaded from the Red Hat ftp site. Unpack in some temporary location. The directory structure in the package is a bit odd, so you need to then copy headers, DLLs and libraries to a standard directory structure (bin, include, lib) for instance under \opt\pthread. Use the pthreadGC2.dll (for GCC built code, no exception handling) version of the DLL. I renamed the corresponding import library to libpthread.dll.a so that a normal -lpthread will find it.

[edit]

GTK+

GTK+ 2.12 and its dependencies (GLib 2.16, Pango 1.20, atk 1.20 and cairo 1.6) are available from the GNOME ftp site.

There are individual runtime and developer zipfiles for each module. Unzip the files into c:\opt\gnome, for instance. Be sure to unzip them all directly into the same directory. That is, don't create intermediate directories for each zipfile or anything like that. The end result should be that your chosen folder, for instance C:\opt\gnome, should contains the subfolders bin, etc, lib and share.

[edit]

pkg-config

pkg-config for Win32 can be found on ftp.gnome.org, too, in http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/.

To work around a bug in MSYS bash, you need to create a file pkg-config.sh somewhere with the contents:

#!/bin/sh
if pkg-config "$@" > /dev/null 2>&1 ; then
res=true
else
res=false
fi
pkg-config "$@" | tr -d \\r && $res

And then set the environment variable PKG_CONFIG=/path/to/that/pkg-config.sh

[edit]

Fake gtk-doc

Fetch the gtk-doc sources. Copy gtkdocize.in to gtkdocize, and edit the new file. Change:

@PACKGAGE@ => gtk-doc
@VERSION@ => 1.3
@PREFIX@ => /opt/gnome
@datadir@ => /opt/gnome/share

Then install a few files into place

cp gtk-doc.m4 /opt/gnome/share/aclocal
cp gtkdocize /opt/gnome/bin
mkdir -p /opt/gnome/share/gtk-doc/data/ 
cp gtk gtk-doc.make /opt/gnome/share/gtk-doc/data

(Replace /opt/gnome with some suitable path you use. Using the same path as where you installed GTK+ and GNOME libraries would be fine.)

[edit]

GNOME platform and desktop libraries

The GNOME platform and desktop libraries needed by Evolution are also available on the GNOME ftp site. Remember to download also the non-GNOME dependencies. The libraries are packaged as individual zipfiles for the runtime and developer parts of each module. Don't bother to download the sources (.tar.gz files) unless you are interested. Unzip them in some suitable location, for instance /opt/gnome.

[edit]

gnome-common

If you are building from SVN, you most probably want to install the gnome-common package first, as the autogen.sh scripts require the gnome-autogen.sh script from gnome-common.

[edit]

Building EDS

All the Win32 changes are merged into the source repository and thus are present in SVN and release tarballs. Thus you only need to check out trunk (or the current stable branch) of evolution-data-server from GNOME SVN to build it on Win32, or use a tarball.

To build e-d-s from SVN, proceed normally in the same style as when building on Unix... Of course, this assumes that your tools are working properly. It might be a good idea to practise first by building something smaller and simpler, like atk. Pay close attention especially that libtool does produce DLLs where it is supposed to.

TorLillqvist runs autogen.sh for e-d-s trunk like this currently:

CC='gcc -mtune=pentium3 -mms-bitfields -mthreads' CPPFLAGS='-I/devel/dist/popt-1.10.2-tml-20050828/include -I/opt/win_iconv/include -I/opt/gnuwin32/include -I/opt/proxy-libintl/include -I/opt/proxy-libintl/include -I/opt/misc/include -I/opt/pthread/include' CFLAGS=-g LDFLAGS='-L/devel/dist/popt-1.10.2-tml-20050828/lib -L/opt/win_iconv/lib -L/opt/gnuwin32/lib -L/opt/proxy-libintl/lib -Wl,--exclude-libs=libintl.a -L/opt/gnu/lib -L/opt/misc/lib -L/opt/pthread/lib' ./autogen.sh --prefix=c:/devel/target/HEAD --disable-static --enable-maintainer-mode --disable-gtk-doc --with-nspr-includes=/opt/mozilla/include --with-nspr-libs=/opt/mozilla/lib --with-nss-includes=/opt/mozilla/include --with-nss-libs=/opt/mozilla/lib

libtoolcacheize

It does not necessarily need to be as complex as above for you. You could keep all "external" dependencies like iconv (either GNU libiconv or win_iconv), gettext-runtime (or proxy-libintl) stuff in the same prefix as the GTK+ and GNOME stack.

The -mms-bitfields option is very important. If you leave that out the software will fail mysteriously at run time.

If you build from a tarball source, you run the configure script directly and not autogen.sh.

[edit]

Building Evolution

The changes for Windows have been merged into the Evolution sources too, so get the sources in a similar way as for e-d-s. One difference is that evolution seems to require newer versions of GNU auto* than EDS, so you need to have fresh versions of them installed in some separate path, for instance /opt/autotools. (Other packages again might not work with "too new" autotools, so it's best not to override the ones from the MSYS Developer toolkit all the time.) TorLillqvist uses this command line currently to configure Evolution trunk:

PATH=/opt/autotools/bin:$PATH CC='gcc -mtune=pentium3 -mms-bitfields -mthreads' CPPFLAGS='-I/devel/dist/popt-1.10.2-tml-20050828/include -I/opt/win_iconv/include -I/opt/proxy-libintl/include -I/opt/gnu/include -I/opt/pthread/include' CFLAGS=-g LDFLAGS='-L/devel/dist/popt-1.10.2-tml-20050828/lib -L/opt/win_iconv/lib -L/opt/proxy-libintl/lib -Wl,--exclude-libs=libintl.a -L/opt/gnu/lib -L/opt/pthread/lib' ./autogen.sh --prefix=c:/devel/target/HEAD --enable-plugins=base --enable-exchange=yes --enable-maintainer-mode --disable-gtk-doc --disable-scrollkeeper --disable-help --with-nspr-includes=/opt/mozilla/include --with-nspr-libs=/opt/mozilla/lib --with-nss-includes=/opt/mozilla/include --with-nss-libs=/opt/mozilla/lib --with-gconf-source='xml::${sysconfdir}/gconf/gconf.xml.defaults'

libtoolcacheize

[edit]

Building Evolution-Exchange

The same principle as for Evolution and EDS. Note that the Win32 changes have been merged only into the current (as of June 2008) trunk of evolution-exchange, not into the gnome-2-22 branch.

[edit]

Tips for running and debugging

  • Environment variables to set for various amounts of debugging spew:
    • GCONF_DEBUG_OUTPUT=y
    • ORBIT2_DEBUG=messages:types (etc, see corba-orb.c for possible flags)
    • BONOBO_ACTIVATION_DEBUG_OUTPUT=y to see output from processes started by boobo-activation-server
  • Starting Evolution (evolution-2.6.exe) can take some time. It's not really doing much, it's more a question of some connection attempts based on invalid cached IORs, or something like that, timing out. It might help somewhat to clean out the ~/.gconfd/saved_state file each time, and maybe the gconf-username and orbit-username subfolders in your temp folder, too.
  • In some network / name server configurations, it's a good idea to create a file etc/orbitrc (in the prefix where you installed ORBit2) with the line ORBNetID=ipaddr.
  • There is code for "end-user relocatability" hopefully in all necessary places. I.e., even though each software module is built with a certain --prefix setting, the GNOME DLLs and executables binaries can still be installed in a random location on the end-user machines. (This isn't rocket science as such, the same feature has been in GIMP, GTK+, Pango etc for ages. It just required *lots* of small patches to the e-d-s and evo code.)
  • It is easiest to install GTK+, GNOME libs, e-d-s and evo all in the same location. You can in theory use separate installation locations for almost all packages, but it will require some experimentation to figure out what needs to be combined with what... (For instance, the gnome and hicolor icon themes probably need to be in the same prefix as GTK+, or GTK+ won't find the icons.)
[edit]

Remarks by kissg (2009-07-12)

[edit]

General notes

The guide above seems to be working almost perfectly - just make sure, you follow each guideline exactly as written. I was able to successfully compile the current stable version of Evolution (2.26.3), but I had to take some extra steps to do so. Please note the followings in case you try to build a recent release:

  • Do not use the latest version of the file tool (file.exe), as it seems to be missing a required switch (-L). 99% of packages use a libtool script, which runs "file -L" to determine the format of a library. The latest win32 version of file doesn't recognize "-L", so libtool won't find any shared libraries. This is not correct, because libtool would create static libraries only, which would have to be included in each binary. The solution is to use the version mentioned in the guide above.
  • Some packages have been upgraded since the writing of the guide - you can safely use the recent versions of those packages, except "regexspencer" (use version 3.8) and "file".
  • If you decide to put packages to separate folders, make sure you include those folders in the PATH environment variable, so gcc and pkg-config will find the required libraries, headers and package config (.pc) files. PATH should include the /bin directory, while PKG_CONFIG_PATH has to contain the "lib/pkgconfig" subdir of the package (<package_dir>/lib/pkgconfig).
  • Make sure, you put each GNOME and GTK+-related packages in the same place (for example, /opt/gnome).
  • When running ./configure, make sure to append the "/include" subdirs of all packages to CPPFLAGS and each "/lib" subdirectory to the LDFLAGS variable. The --enable-maintainer-mode option is not required, if you build from a source tarball.
  • During the build process (or while running the configure script), you most likely will get some errors. Don't panic, in most cases, it's easy to solve the problem (see the list below).
  • Recent versions of Evolution use the libical package. A precompiled version is available from the GNOME ftp site (http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/), just download the binaries and the developer files to /opt/misc and everything will be fine. Unfortunately, the package doesn't contain a .pc file, so you'll have to create it manually. Use this as a template:
prefix=/opt/misc
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: ical
Version: 0.43
Description: iCalendar implementation for C++
Requires:
Libs: -L${libdir} -lical
Cflags: -I${includedir}
  • Some packages might need Python to build correctly. Download Python for Windows available at http://www.python.org/download/releases/2.6.2/ and install it to /opt/python. Don't forget to include the installation path in the PATH environment variable.
  • To successfully build Evolution on Windows, you'll need the python implementation of libxml2. Download the installer for version 2.6 (http://users.skynet.be/sbi/libxml-python/) and install it. The installer will automatically configure python to use the module.
[edit]

Common build errors

  • Compiling fails because of some undefined functions/variables etc.: This is because one or more required header files could not be included to the source. Double check, that you have all the dependencies installed. If you installed from a pre-built package, make sure, you've downloaded the developer package (<package_name>-dev), too, and you've included the headers in the CPPFLAGS variable.
  • Getting a lot of "<library_name> seems to be moved" warnings from libtool: in case you see such a warning, just ignore it. It's because the library directory defined in the library's .la file is a relative path (eg. "../"). Libtool expects an absolute path, that's why it shows the warning message.
  • Libtool cannot find shared libraries, but they are in the right place: this is a regression in the latest "file.exe" utility. Downgrade to version 4.13, and these kind of warnings will disappear.
  • Syntax errors while running make: syntax errors may appear during build, because msys uses quite old versions of the common build tools, like make, libtool and libtoolize. These tools are available from MinGW, too, with much recent versions. The solution is to use the tools shipped with mingw. To achieve this, just rename the files /bin/make, /bin/libtool, /bin/libtoolize to some random name.
  • Command not found while running scripts: if you experience, that some scripts (eg. perl or python scripts) fail to run, open the script, and check the path at the first line. It should point to the binary, which has to execute that particular script. For example, if you installed Python to "/opt/python", correct the path at the first line of each python script to "#!/opt/python/python".
  • "Undefined reference" error message while linking a library: I got an error message like that during the build of the CalDAV module (libecalbackendcaldav.dll). The linker tool (ld.exe) was unable to find a function, which should have been defined in libsoup. After some research, I found, that the missing function is only used for debugging purposes, so I decided to comment out the relevant code in e-cal-backend-caldav.c. This solved the problem in that case, but I cannot guarentee that it will work in other situations. Probably the libsoup library was a bit old or was built without including debugging code, I'm not sure. This trick is only useful if some non-critical code causes the problem. In other cases, you must get the latest version of the package, which seems to miss some functions required by Evolution. If there is no prebuilt version of the package, you have to build it yourself.
Retrieved from "https://go-evolution.org/index.php/Building_Evolution_on_Windows"