		Libpng
		------

Imlib11 is linked with libpng12 (nee libpng3).  This is in accordance
with the practice of Redhat.  The GDK version of imlib, being part of
GNOME 1, has remained linked with libpng10 (a.k.a. png2).  

Two recent discussions on this point are:
  http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01256.html
  http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00653.html



		Loadable Modules
		----------------

Gdk_imlib can be built with all the graphics libs linked in, or it
can be built with a set of loadable modules, one for each graphics
format.

For most Debian releases, the second option was used.  This worked
fine until upstream version 1.9.13 in which the loadable modules
started linking against libgdk_imlib itself.  This triggered a libtool
bug related to DESTDIR (see below).  I didn't figure out the cause or
the fix at the time, so I resorted to the second option.

With imlib 1.9.14-2, I disabled the module code, and linked all the
graphics libraries directly into libgdk_imlib.  This led to requiring
gdk-imlib-dev to depend on the corresponding -dev packages for each
graphics library.

Starting with 1.9.14-5, we're going back to loadable modules.  Now the
trick with libtool is that at install time, each shared object (shared
lib or loadable module) is re-linked.  Consider the case of a shared
module, e.g. libimlib-bmp.so, which is linked against libgdk_imlib.

The make rules re-link and install libgdk_imlib first.  Then
libimlib-bmp.so is re-linked before installation.  Normally, this is
fine, because libgdk_imlib is in the correct location and can be found
by the linker.

However, when building a Debian package, the files are first installed in
a staging area (i.e. debian/tmp).  The linker is not expecting to look
there when re-linking libimlib-bmp.so, and thus it fails.

This is a known problem in the libtool community, see e.g. the
notes on "The DESTDIR bug" at

    http://fink.sourceforge.net/doc/porting/libtool.php

A patches to libtool was provided by Bruno Haible, and later updated
by Ewald Snel

    http://mail.gnu.org/pipermail/libtool/2002-April/006268.html 
    http://mail.gnu.org/pipermail/bug-libtool/2002-February/003019.html 

Unfortunately, these did not work.  I tried the patch from Sam Couter
at http://bugs.debian.org/57087 that worked!

  *** BIG FAT WARNING ***
  Do not run "libtoolize" without a patched libtool!



		Devel Dependencies
		------------------

Library libImlib (package imlib11) is directly linked to several
libraries, so imlib11-dev has to depend on the corresponding -dev
packages.

imlib11 deps (from shlibs)		imlib11-dev deps
--------------------------		--------------

libjpeg62				libjpeg62-dev
libpng2(>=1.0.12)			libpng2-dev
libtiff3g				libtiff3g-dev
libungif4g (>= 4.1.0b1)			libungif4-dev
xlibs (>> 4.1.0)			xlibs-dev
zlib1g (>= 1:1.1.4)			zlib1g-dev


	A Caveat
	--------

However, see Bug #152364.  The package gnome-libs generates a
"gnome-config" script using the list of libraries emitted by
"imlib-config --libs-gdk".  Historically, gdk-imlib has always built
the modules, and consequently imlib-config did not list the individual
graphics libs.

In March, a new release came out that caused me some problems.  I
couldn't get the modules built correctly, so I disabled them, linking
all the graphics libs into gdk-imlib.

A new gnome-libs comes out, and picks up all the graphics libs from
"imlib-config --libs-gtk".

For version 1.9.14-5, I straightened out the mess with imlib so that I
could build the modules again.  I didn't know anything about
gnome-config picking up the graphics libs, so I naively thought I
could remove the dependencies.

Boom!  See Bug #152364.

In version 1.9.14-6, I reverted package gdk-imlib-dev to list the
graphics libs until such time as gnome-libs gets rebuilt.  The gnome
libs were updated by 2002-07-29, so version 1.9.14-7 removes the
graphics lib dependencies from gdk-imlib-dev, again.



		Plugins
		-------

The shared libs in gdk-imlib1 confuse dh_makeshlibs.  The result is
a bunch of duplicated entries in the shlibs file.  I fixed this
by providing a shlibs file for gdk-imlib which thankfully does 
override the generated one.  So the warnings can be ignored.


		Source Changes
		--------------

Any changes to a generated file such as Makefile.in or configure is a
side-effect of either a change to the corresponding source file
(i.e. Makefile.am or configure.in), or simply a result of running
autoconf & automake prior to building the Debian source package.  As
such, these changes should be ignored.

The files config.guess and config.sub are refreshed manually from
/usr/share/misc.


* config-quoting.patch

Quote autoconf macro arguments, to please autoconf 2.53.
Posted to upstream Bugzilla 2002-07-07.


* gxlibs.patch

Ensure libgdk and libgtk are linked with gdk_imlib.
Posted to upstream Bugzilla 2002-07-07.


* moduledir.patch

Install helper modules into configurable moduledir.
Posted to upstream Bugzilla 2002-07-07.


* tload.patch

Build test programs (both Imlib and gdk_imlib versions) to
test that the linking is correct, and modules can be found.


* palfile-buffer.patch

Bug fix to prevent overwriting a too-short buffer.
Posted to upstream Bugzilla 2002-07-07.


* fallback-doc.patch

Debian specific.  Emit diagnostic pointing to README file that
explains what to do when "all fallbacks failed."


* bpp16-CVE-2007-3568.patch

Fix DoS via a BMP image with a Bits Per Page (BPP) value of 0
