I tried to package some software which uses gtk+ and dpkg-shlibdeps just
hammers my output with messages like

dependency on xxxx could be avoided if ....


I checked your /usr/lib/pkgconfig/gtk+-2.0.pc and noticed that there is a
Require statement with many other pkg-config files. /usr/lib/libgtk-
x11-2.0.so.0.2000.1 doesn't seem have have so have unresolved symbols. So
either the header files generate code which creates otherwise unresolved
symbols or you don't use Require in /usr/lib/pkgconfig/gtk+-2.0.pc correctly.
Please see the difference with Require.private in gtk+-2.0.pc:

$ pkg-config --libs gtk+-2.0
-lgtk-x11-2.0
$ pkg-config --cflags gtk+-2.0
-pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -
I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -
I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 -
I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include

$ pkg-config --libs --static gtk+-2.0
-pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lXinerama -lXi 
-lXrandr -lXcursor -lXcomposite -lXdamage -lgdk_pixbuf-2.0 -ltiff -ljpeg -
ljasper -lpangocairo-1.0 -lXext -lXfixes -lcairo -lgio-2.0 -lresolv -lpixman-1
-lpng12 -lm -lxcb-render-util -lXrender -lxcb-render -lX11 -lpthread -lxcb -
lXau -lXdmcp -lpango-1.0 -lfontconfig -lexpat -lfreetype -lz -lgobject-2.0 -
lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0
$ pkg-config --cflags --static gtk+-2.0
-pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -
I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -
I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 -
I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include

And now how it looks today with Require:
$ pkg-config --libs gtk+-2.0
-pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 
-lm -lpangocairo-1.0 -lcairo -lgio-2.0 -lpango-1.0 -lfreetype -lfontconfig -
lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0
$ pkg-config --cflags gtk+-2.0
-pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -
I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -
I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 -
I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include

$ pkg-config --libs --static gtk+-2.0
-pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lXinerama -lXi 
-lXrandr -lXcursor -lXcomposite -lXdamage -lgdk_pixbuf-2.0 -ltiff -ljpeg -
ljasper -lpangocairo-1.0 -lXext -lXfixes -lcairo -lgio-2.0 -lresolv -lpixman-1
-lpng12 -lm -lxcb-render-util -lXrender -lxcb-render -lX11 -lpthread -lxcb -
lXau -lXdmcp -lpango-1.0 -lfontconfig -lexpat -lfreetype -lz -lgobject-2.0 -
lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0
$ pkg-config --cflags --static gtk+-2.0
-pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -
I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -
I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 -
I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include

So the cflags are untouched, but the libs are a lot cleaner for non static
compilations. Please change it to Require.private or give a good reason not to
do so (broken build systems of other applications are no good reason). It
should cleanup many dependencies in our repository which aren't needed at all
and only happens due to gtk+-2.0's bad pkg-config file.
Debian Release: squeeze/sid
  500 unstable        ftp.uni-kl.de
  500 unstable        ftp.debian.org
    1 experimental    ftp.debian.org
--- Package information. ---
Depends                      (Version) | Installed
======================================-+-=================
libgtk2.0-0               (= 2.20.1-1) | 2.20.1-1
libgtk2.0-common                       | 2.20.1-1
libc6                       (>= 2.2.5) | 2.10.2-9
libglib2.0-0               (>= 2.23.6) | 2.24.1-1
libglib2.0-dev             (>= 2.23.6) | 2.24.1-1
libpango1.0-dev              (>= 1.20) | 1.28.0-1
libatk1.0-dev              (>= 1.29.2) | 1.30.0-1
libcairo2-dev           (>= 1.6.4-6.1) | 1.8.10-4
libx11-dev              (>= 2:1.0.0-6) | 2:1.3.3-3
libxext-dev             (>= 1:1.0.1-2) | 2:1.1.1-3
libxinerama-dev       (>= 1:1.0.1-4.1) | 2:1.1-3
libxi-dev               (>= 1:1.0.1-4) | 2:1.3-4
libxrandr-dev            (>= 1:1.2.99) | 2:1.3.0-3
libxcursor-dev                         | 1:1.1.10-2
libxfixes-dev           (>= 1:3.0.0-3) | 1:4.0.4-2
libxcomposite-dev       (>= 1:0.2.0-3) | 1:0.4.1-1
libxdamage-dev          (>= 1:1.0.1-3) | 1:1.1.2-1
pkg-config                             | 0.24-1
libxml2-utils                          | 2.7.7.dfsg-2


Recommends      (Version) | Installed
=========================-+-===========
python           (>= 2.4) | 2.5.4-9
debhelper                 | 7.4.20


Suggests           (Version) | Installed
============================-+-===========
libgtk2.0-doc                |

Even though I'd really like to do that, I'm not still convinced we can do it in
GTK+. Since GTK+ exports APIs of those libraries in its public headers,
applications linking to GTK+ should link to those libraries too. Or do you say
cflags would be enough, but not libs?

Emilio

Emilio Pozuelo Monfort wrote:

If they are using other libraries then they must use their pkg-config
anyway... otherwise they are broken. If the programs just use some structs or
other things which are declared in their header then the cflags just looks
like before and nothing has changed for them.

Or do you mean that there is a gtk_blablubfoo() which just is a define or
static inline function in their headers which uses glib_foobar()? It would
make gtk+-2.0 an evil library and prevent Requires.private.

Best regards,
	Peter

Le lundi 24 mai 2010 à 11:49 +0200, Peter Fritzsche a écrit :

For example some GTK+ functions return structures or types that are
defined in Glib or Pango.

Thats ok. Those structure types have nothing todo with symbols which must be
resolved by libraries. The header  stuff is still exported by --cflags as before
- only the "third party" libraries will not appear using --libs when not using
it together with --static.

Best regards,
	Peter