Building gdk-pixbuf as 64-bit (using MSVC)

[johne53 (John Emmas)]

Is this the right place for reporting problems with gdk-pixbuf or does it have its own forum somewhere??

Basically… a few years ago I built the GTK+ support stack for Windows, using MSVC (which was a supported compiler back then). At the time, gdk-pixbuf was at version 2-36 although I only built the stack libs as 32-bit.

I’m now in the process of resurrecting everything and updating it all to 64-bit. Everything seems to have built successfully except for a strange runtime issue with gdk-pixbuf.

‘gdk-pixbuf-io.c’ contains a function called _gdk_pixbuf_get_module(). Its execution varies (depending on whether or not I #define GDK_PIXBUF_USE_GIO_MIME). For a 32-bit build it doesn’t seem to have much effect whether I #define it or not but things are very different for a 64-bit build…

Towards the end of _gdk_pixbuf_get_module() there’s a check to see if a variable called selected got set. For my 32-bit build it’s always correctly set by the time that test gets reached (i.e. it’s always non-NULL). But things are very different for a 64-bit build…

If I build with GDK_PIXBUF_USE_GIO_MIME #defined to 1, a 64-bit build will fail to read any image file of any type. And if GDK_PIXBUF_USE_GIO_MIME is undefined, some file types succeed (e.g JPG and BMP) whereas most fail (TIF / PNG etc).

Does this make sense to anyone here? For example does gdk-pixbuf need me to specify some extra #define(s) when building as 64-bit??

[Edit…] Or alternatively… do I need to #undef G_OS_WIN32 when building as 64-bit? I couldn’t find anything called G_OS_WIN64 so I’ve assumed I’ll still need G_OS_WIN32

[ebassi (Emmanuele Bassi)]

You can have a look at how gvsbuild builds gdk-pixbuf.

The “use GIO MIME detection” code relies on GIO being available; on Windows, GIO will use the registry to match the content type.

Alternatively, if you don’t want to rely on the GIO content type implementation, you will need to rely on every pixbuf loader’s format detection.

[johne53 (John Emmas)]

Thanks Emmanuele, I’ve gotten a little further this morning…

gdk-pixbuf-io.c contains a function called _gdk_pixbuf_get_module_for_file() which contains the following line:-

size = fread (&buffer, 1, sizeof (buffer), f);

For each format that fails (e.g. PNG etc) fread() is returning a value of 5 whereas the successful formats return a much higher value (typically a few thousand). I tried changing ‘size’ to be of type size_t (rather than int) but that hasn’t helped. This only happens if I build as 64-bit.

Although I’m building from gdk-pixbuf-2-36 I’ve checked git master but it doesn’t look like that function’s changed. I must admit, I’m baffled at the moment

[johne53 (John Emmas)]

gdk_pixbuf_new_from_file() contains this line:-

f = g_fopen (filename, "rb");

If I change g_fopen() and use plain old fopen(), the fread() call now now returns the same value as a 32-bit build! Unfortunately I get a crash later but at least it’s encouraging. It looks like g_open() has a problem opening certain files!! Or is there maybe a g_read() somewhere that should be getting used instead of fread()??

Something to investigate tomorrow…

[johne53 (John Emmas)]

It turned out to be an error on my part… I’d forgotten that when libraries use functions like _fopen() / _fdopen() etc you can’t just use them “as is” (not in MSVC anyway). First, you need to set a translation variable called _fmode (which determines whether to open files as text files or binary files). It’s one of those annoying “Windows things” that I’d totally forgotten about - so what was happening was that image files would sometimes get opened in text mode, which then made them unreadable. I’m not quite sure why I only saw the problem when using g_fopen() but I’ve now configured things for binary mode and that’s fixed it.!