Re: libgdk-pixbuf reciprocal dependency - what am I not understanding?

[John Emmas <johne53 tiscali co uk>]

On 21 Nov 2010, at 09:56, Tor Lillqvist wrote:

> The Visual Studio project files for GTK+ might have worked at one
> specific point in time when I added them, but not later...  it says in
> the build/win32/vs9/README.txt, "Note that all this is rather
> experimental". Luckily there is now a person (Chun-wei Fan)
> maintaining them, but as far as I can see he is working on the
> development branch, i.e. what will become GTK+ 3.
>
> Hmm, or are you actually talking about the "makefile.msc" files and
> not the Visual Studio project files?
Thanks for replying so comprehensively Tor.  In fact, I was actually thinking about the VS project files - 
but I didn't realise that gdk-pixbuf had been split into a separate package now.  That makes a bit more 
sense.  I think I must have an early version.


> > When I try to build libgdk_pixbuf-2.0_0.dll with INCLUDE_bmp defined, it fails with unresolved externals 
> > because I haven't yet built libpixbufloader-bmp.dll.  But if I try to build libpixbufloader-bmp.dll it 
> > also fails if libgdk_pixbuf-2.0_0.dll hasn't yet been built.  So with that preprocessor directive defined, 
> > neither module will build until the other one's been built.  Obviously this can't be right.  I suspect 
> > that I should only #define INCLUDE_bmp for one of the builds but not the other.  Or maybe I should be 
> > building libpixbufloader_bmp as a static lib, instead of a DLL.
>
> Hmm, hard to say what exactly is going wrong here, there are no
> circular dependencies as far as I know.

Here's what I discovered from doing some tests this morning:-

it seems as if INCLUDE_bmp causes gdk_pixbuf_io_init() to look for an internal (i.e. statically linked) 
bitmap handler (these seem to be known as "builtin modules").  Likewise for the other INCLUDE_nnn directives. 
 Regardless of whether an internal handler got found, as long as USE_GMODULE is defined to be nonzero, 
gdk_pixbuf_io_init() will then go on to look for external handler modules (dynamic libraries).  The error 
message I encountered will only get displayed if no internal handlers and no external handlers were found.

So, sticking with BMP as my example, it looks as if 'USE_GMODULE' and 'INCLUDE_bmp' are (more or less) 
mutually exclusive directives.  INCLUDE_bmp should be defined if I want to link statically to the BMP 
handler.  USE_GMODULE should be defined if I'm going to be using an external (dynamically linked) handler.  
The reason I had (what looked like) a circular dependency was because I defined INCLUDE_bmp when I was 
intending to link dynamically to the handlers..!

But here's something interesting....  from my (admittedly limited) investigations this morning, it seems as 
if a list of handlers gets maintained with the external ones prepended to the list (suggesting that an 
external handler will take precedence over an internal handler for the same type?)  I don't know if that's 
intentional or just a lucky coincidence (I'd guess intentional).  If it's intended behaviour, it might make 
some sense to build libgdk-pixbuf with a range of internal handlers linked statically (as fallback options, 
say).  External handlers (if found) would then over-ride them.  But I'm only guessing.  Maybe that's just 
wishful thinking!

John