Compiling libpurple in Visual Studio

[Nick Hebner]

On 5/28/07, David Byron <dbyron at dbyron.com> wrote:
>
> On Monday, May 28, 2007 @ 12:00a, Nick Hebner wrote:
>
> > Inspired by David Byron's recent successful tackling of
> > libpurple use from MSVC, I decided to give the entire
> > compilation of libpurple in Visual Studio a try (in order to
> > build with debuggable symbols).
>
> > My method:
> >
> > 1. Create an empty dll project
> >
> > 2. Add version.h, and config.h from pidgin root
>
> I don't see either of these files in the root of the pidgin-2.0.1 tarball.
> I do see a version.h in the libpurple directory and config.h.mingw in the
> root.  Are those the files you mean?


Yes, you are right. I think that config.h.mingw gets copied to
config.hduring the mingw compile.

> 3. Add all .c and .h from libpurple directory (except
> > purple-client* files)
> >
> > 4. Add libpurple\win32 directory (only need .c, .h, and .rc
> > files)
> >
> > 5. Apply attached patches (1 for libpurple, and 1 for win32
> > directory)
>
> I didn't a patch for prpl.h so it doesn't unconditionally include unistd.h
> .
> Do you have unistd.h on your machine?


In mtn (ver 2.0.2) this include is guarded.

> My Visual Studio Project Properties:
> >
> > C/C++::General::Additional Include Directories:
> > ------------------------------------------------
> > $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\gtk_2_0\include
> > $PIDGIN_DEV_ROOT\win32-dev\libxml2\include
>
> How did you get Visual Studio to find libpurple/win32/win32dep.h?  I had
> to
> add libpurple/win32 as an include path as well.


Yes, you are right again, I forgot to mention that.

> C/C++::Advanced::Force Includes:
> > ------------------------------------------------
> > winsock2.h; config.h
>
> Isn't it more "normal" to add HAVE_CONFIG_H to
> C/C++::Preprocessor::Preprocessor Definitions than to use this force
> includes mechanism?  Anyway, that's what I did and it seems to work.


That is probably the right way to do it.

> Linker::General::Additional Library Directories:
> > ------------------------------------------------
> > $PIDGIN_DEV_ROOT\win32-dev\gtk_2_0\lib
> > $PIDGIN_DEV_ROOT\win32-dev\libxml2\lib
> >
> > Linker::Input::Additional Dependencies:
> > ------------------------------------------------
> > glib-2.0.lib
> > gmodule-2.0.lib
> > gobject-2.0.lib
> > gthread-2.0.lib
> > libxml2.lib
> > intl.lib
> > iconv.lib
> > ws2_32.lib
>
> > Linker::Input::Module Definition File:
> > ------------------------------------------------
> > libpurple.def (generated by the mingw compile)
>
> At what point in your recipe did you build with mingw?  It would be great
> to
> not have to do this to minimize the build tool dependencies (i.e. keep
> developers from having to deal with mingw tools at all).


I started by following your footsteps in getting libpurple to work with
nullclient in VS, so I had to build with mingw first. At first, I compiled
without using a def file, and found that no symbols were exported in the
resulting dll. Adding the def file fixed this. The alternative would be to
specify all exported functions with __declspec(dllexport), but thats a lot
of functions... I agree that dependence on another toolchain just for this
is lame. I would say that distribution of the def file itself would be
reasonable except for maintaining api changes.

Thanks for picking up the ball here.
>
> -DB
>
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20070528/a0a46599/attachment.html>