MSVC Portability

Daniel Atallah daniel.atallah at gmail.com
Wed Apr 3 16:04:20 EDT 2013


On Wed, Apr 3, 2013 at 3:21 PM, Zoltán Sólyom <z-ismeretlen at freemail.hu> wrote:
> 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.
>>
>> -D
>>
>> -D
>>
>
> 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 wasn't suggesting taking the pre-compiled binaries from that site,
but rather for you to use his solution as an example for compiling
glib.
There actually might be working VS build files in the main glib source
- you might want to check that too.

> 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.

It surely is caused by the mixing of the different C Runtimes between
the VS versions - you can't mix handles from different C Runtimes.

I think it's asking for trouble to go down the path that you're
suggesting.  It shouldn't be all that complicated to compile glib and
use the real fix.

-D




More information about the Devel mailing list