1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
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."
|
