building an MSVC app with libpurple

[Daniel Atallah]

On 5/25/07, Lee Roach <phroggster at gmail.com> wrote:
> David Byron wrote:
> > dependency walker did the trick.  When I type glib-2.0.lib into MSVC (really
> > Visual Studio 8) it ends up looking for glib-2.0.dll.  When I take it out
> > altogether I get unresolved externs for things like _g_timeout_add and
> > _g_main_loop_new.  I don't have a libglib-2.0-0.lib but I do have
> > libglib-2.0-0.dll so I put that on the link line.  Unfortunately this in a
> > dll that MSVC can't read.  MSVC fails to link with this error:
> >
> > ...\src\glib-2.12.11\bin\libglib-2.0-0.dll : fatal error LNK1107: invalid or
> > corrupt file: cannot read at 0x2B8

I wouldn't expect this to work because I don't believe that MSVC can
link against a dll directly in the way that gcc can (I could be
mistaken though).

> > Are there some tricks to convert libglib-2.0-0.dll into a format MSVC can
> > use?
> >
> What you'll want to do in MSVC is specify your link path to
> "$PIDGIN_DEV_ROOT\win32-dev\gtk_2_0\lib" (plus others as needed) and
> specify "glib-2.0" (possibly "glib-2.0.lib") as the import lib.
> $PIDGIN_DEV_ROOT not being literal, but instead the same folder you've
> used to compile pidgin and libpurple out of. You should not need to
> rename any of the files extracted from Tor's zips or built by libpurple.

This is exactly right - Tor's dev package already contains a MSVC link
library (glib-2.0.lib).

> The thing Daniel hasn't mentioned, which I meant to reply to your first
> post on earlier but ran into more pressing problems, is that you'll need
> to make sure to inform your program on where to load load
> libglib-2.0-0.dll from. See pidgin/win32/winpidgin.c for an example of
> how to do it properly.
>
> Simply query the registry at {hklm|hklu}\SOFTWARE\GTK\2.0\Path to
> determine the installed GTK runtime path, and SetDllDirectory (if
> available, otherwise SetCurrentDirectory) with that result plus "\\bin".
> Having never used nullclient, I'm not sure where that'll need to be
> added, but it'd have to be called before any code references functions
> that are exported by glib. In other words, before using init_libpurple()
> or any glib calls, make sure the OS knows where it and it's dependencies
> can be loaded from.

I actually purposefully didn't mention this because I don't think that
it is the right solution for a native client.  There are far fewer
dependencies for libpurple than Pidgin and there is no need for a
libpurple client to depend on the GTK+ runtime.  It would make more
sense to use a local copy of the appropriate dependencies and not have
to worry about installing them separately.

-D