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

[Tor Lillqvist <tml iki fi>]

> I'm trying to build libgdk-pixbuf from source (actually, I'm building the whole of libgtk-win32 but let's 
> concentrate on libgdk-pixbuf, since that's where my current confusion lies).

What version of GTK+? In the current version of GTK+, 2.22.x,
gdk-pixbuf has been split out into a separate source package.

> I've figured out that libgdk-pixbuf relies on helper modules called 'loaders' which handle the various 
> image formats (bmp, jpeg, png etc).

Yeah, and note that the word "module" is quite overloaded. In this
case it means "piece of software that can be either a dynamically
loaded library (DLL on Windows), or just object files linked into an
executable (the gdk-pixbuf DLL).

> ÂThese loaders don't get built by the supplied VC++ projects

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?

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

> I've also noticed (in the makefile) a possible project called libstatic_pixbufloader_bmp - so does one 
> normally build the loaders both as static libs AND dynamic libs?

Nope. On Unix, what seems to be "normal" is that one builds the
loaders as dynamic libs. In my Windows builds I have built them into
the gdk-pixbuf library (DLL), and that is also what the VS project
files do. In the VS project files the loaders are just built as normal
object files and linked into the gdk-pixbuf DLL, as far as I can
recall, not first collecting them pointlessly into static libraries.
When using libtool (i.e. in "normal" Unix builds and builds for
Windows using MinGW) there are static libraries built but that is just
a somewhat unnecessary roundabout way to do it IMHO. The loader object
files could as well be linked directly into the gdk-pixbuf shared
library.

> Âe.g. are there some kind of stub functions which get replaced by the actual loader functions at run time, 
> as the appropriate DLL's get found?

Er, no, you are now overcomplicating it.

--tml