Re: MS Windows packages and modularity
- From: "Daniel Atallah" <daniel atallah gmail com>
- To: "Tor Lillqvist" <tml iki fi>
- Cc: gtk-app-devel-list gnome org, Allin Cottrell <cottrell wfu edu>
- Subject: Re: MS Windows packages and modularity
- Date: Mon, 20 Oct 2008 19:57:44 -0400
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]