Re: MS Windows packages and modularity

["Daniel Atallah" <daniel atallah gmail com>]

On Mon, Oct 20, 2008 at 7:20 PM, Tor Lillqvist <tml iki fi> wrote:
>>> Was there a compelling reason for this reversion?
>
> Not really. As has already been said, if/when the GDI+ -based pixbuf
> loaders would be used, then it would hopefully be 100% clear that it
> makes sense to build them as built-in in the gdk-pixbuf DLL. But now
> when I was forced to revert to the libgpej and libtiff -based loaders,
> there are two more or less equivalent choices, both which have their
> disadvatages: either 1) build separate png, jpeg and tiff loaders,
> which means there are more files to distribute for people who want to
> minimize the number of files in the GTK+ runtime and still be able to
> load jpef or tiff files, or 2) build built-in loaders which means the
> png, jpeg and tiff DLLs are required even for a GTK+ runtime used in a
> situation where it doesn't use any png, jpeg and tiff files.
>
> Would the best solution be to build the png, jpeg and tiff libraries
> as static libraries, and link them statically into gdk-pixbuf?

I don't particularly like the built-in loaders, and statically linking
the dependent library doesn't address my concern.

There are occasionally security vulnerabilities in these libraries
(most recently libpng and libtiff (which is still unpatched)) - I like
being able to update the library versions without changing GTK+.  It
is particularly handy that I can disable the tiff loader via the
gdk-pixbuf.loaders file until there is an updated libtiff.

-D