z-ismeretlen at freemail.hu
Wed Apr 3 15:21:49 EDT 2013
On 13/04/03 16:30, Daniel Atallah wrote:
>> After the first run with the DLLs compiled in Visual studio, there was an
>> access violation. I found that the pointer to FILE structure returned by
>> g_fopen is not compatible with file operations in MS libraries ( Does this
>> state the same?
>> https://developer.gnome.org/glib/2.28/glib-File-Utilities.html#g-fopen ).
> Yes that's pretty much the expected behavior because it's using a
> different C Runtime.
> I think the correct solution is to compile glib against the same C
> Runtime that you'll be using with pidgin.
> http://gtk.hexchat.org/ has some documentation about building the
> whole stack - you'll only care about the things above glib, so it is
> substantially simpler.
I took the compiled .lib and .dll files from that site, started up
Visual Studio 2010 (I have that also) and included what libpurple
missed. (I copied the whole VS project to a new folder and only added
the required .lib files one by one when it complained, so there is no
file from the original glib for sure.) Unfortunately the moment
libpurple calls fwrite, it still causes an access violation.
I can't tell for sure whether this is caused by the VS2012 install
overwriting stuff from the VS2010, but I don't want to spend another
week just to see that the rebuilt glib won't work either. Now, I'm not
saying it is impossible, but I'll let others with stronger determination
do it. :) If it is not a viable option to modify the libpurple source,
my define hack with the g_fopen replacement will suffice for now.
More information about the Devel