Compiling libpurple with MS Visual C++ 2008 Express

[Lee Roach]

I've seen several mailings on this list previously about compiling libpurple
with a native win32 compiler and had to point out that it is in fact
possible. I had been curious myself for quite a while, and have finally
confirmed that it works. While this method could theoretically be used to
build the entire pidgin sources, we lose a key benefit of using MSVC at all:
debugging. Since we have no IDE debugging abilities, I see no reason to
pursue this any further. Not to mention, we lose support for anything older
than Windows 2000.

My original goal was to initially compile nullclient and dependencies, and
then design a native UI on top of it.

I used Visual C++ 2008 Express Edition [1] (which is free, to some extent of
the word), combined with the Windows Driver Kit (version 6001.18001) [2],
and GTK+ 2.12.11 (for both dev and runtime) with Glib 2.16.5. MSVC 6 would
probably be a lot simpler, but I have long since lost that cd, and it's
antiquated nature does't help when it comes time to build a modern UI. The
GTK and Glib versions don't really matter either, I just had those versions
handy.

The main difficulty when compiling with an MSVC newer than 6.0 is that it
doesn't supply the link libraries for the proper version of the C runtime
library, and libpurple will break severely if it's compiled against anything
other than msvcrt.lib/dll. Since all of libpurple's dependencies use msvcrt,
we can't build it with msvcrt9 or whatever they call it today, and are
forced to find a workaround. The workaround for building against the
OS-supplied runtime instead of the Visual Studio supplied one is available
in this blog [3], or a more condensed version in this blog [4].

You'll need to start off by following the instructions at BuildingWinPidgin
[5] to setup your environment, and then 'make install' to produce everything
the traditional way. This is needed to build things that MSVC will require,
like version.h, libpurple.def, and a couple others.

I have posted my libpurple.vcproj at [6]. This should go in
pidgin-<version>\libpurple\win32 for least headaches, but you'll probably
have to modify it regardless, or follow the following paragraph instead, to
create it from scratch.

Create a simple blank dll project in Visual C that outputs
Release/libpurple.dll and add the following files to it's control:
libpurple/*.c libpurple/win32/*.c libpurple/win32/*.rc libpurple/*.h and
libpurple/win32/*.h. Switch to Release build, and hit project->properties,
scroll to C/C++>Preprocessor and add these defines:
HAVE_CONFIG_H;_CRT_SECURE_NO_WARNINGS. Scroll to General, and add Additional
Include Directories: PIDGIN_DEV_ROOT\pidgin-2.5.0
PIDGIN_DEV_ROOT\pidgin-2.5.0\libpurple
PIDGIN_DEV_ROOT\pidgin-2.5.0\libpurple\win32
PIDGIN_DEV_ROOT\win32-dev\gtk_2_0\include
PIDGIN_DEV_ROOT\win32-dev\gtk_2_0\include\glib-2.0
PIDGIN_DEV_ROOT\win32-dev\gtk_2_0\lib\glib-2.0\include
PIDGIN_DEV_ROOT\win32-dev\libxml2-2.6.30\include \WinDDK\6001.18001\inc\crt;
modifying the paths as needed. Scroll to Linker, and add the following
Additional Library Directories: win32-dev\gtk_2_0\lib
win32-dev\libxml2-2.6.30\lib \WinDDK\6001.18001\lib\w2k\i386
\WinDDK\6001.18001\lib\crt\i386; again, modifying the paths as needed.
Scroll to Linker->Input and set Module Definition File to the libpurple.def
that you generated in Cygwin; for me, this is
$(ProjectDir)..\..\libpurple.def. This is needed because libpurple doesn't
use __declspec(dllexport) anywhere, although someone at some point in time
had mentioned using G_EXPORT everywhere, which would just work (tm) instead.
On the same tab, add the following to Additional Dependencies: glib-2.0.lib
gmodule-2.0.lib gobject-2.0.lib gthread-2.0.lib intl.lib libxml2.lib
Ws2_32.lib msvcrt.lib and the all important msvcrt_win2000.obj.

The libpurple sources should now build successfully, and the libpurple.dll
that's output can be used as a drop-in replacement for the MinGW built one,
and you can now sit back and have a beer, and realize you almost completely
wasted your time.

After doing the above steps, I came to the realization that compiling a
libpurple UI in MSVC would be better linked to a standard MinGW-built
libpurple, even if we lose the ability to debug both UI and libpurple
simultaneously. At least libpurple can still be debugged via gdb, and the UI
can still be debugged via MSVC, which is better than not being able to debug
either one. However, it's still not as good as compiling all of libpurple's
dependencies in MSVC, but I don't think anyone has the time to do that
properly, nor the desire.

I hope I at least answered a few questions for those desiring a similar
MSVC-built libpurple UI, and perhaps shed some light on why there is still
little movement in this direction.

[1]: http://www.microsoft.com/express/download/default.aspx
[2]:
https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=148&DownloadID=11295
[3]:
http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/
[4]: http://nn1234.wordpress.com/2008/04/11/vc-90-msvcrtdll-windows-95/
[5]: http://developer.pidgin.im/wiki/BuildingWinPidgin
[6]: http://www.filefactory.com/file/c32e9e/n/libpurple_vcproj

--Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20080823/2af8144d/attachment-0001.html>