Bug#582865: [libglib2.0-dev] pkg-config requires too many libraries

[Simon McVittie]

tags 582865 + wontfix
thanks

On Mon, 24 May 2010 at 11:29:26 +0200, Peter Fritzsche wrote:
> I checked your /usr/lib/pkgconfig/gmodule-2.0.pc and noticed that there is a 
> Require statement with many other pkg-config files. libgmodule-2.0.so.0.2400.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 gmodule-2.0:

For better or worse, GLib upstream intend for the ABI of the GLib cluster
of libraries to be "if you use the pkg-config for one, you can rely on
having the API and ABI of the ones lower in the stack". So
a pkg-config check for gio-2.0 gives you all of GIO, GObject, GLib,
GThread.

> It 
> should cleanup many dependencies in our repository which aren't needed at all 

GLib, GObject, GIO, GModule and GThread are all one big library package
(libglib2.0-0) so dpkg-shlibdeps is incorrect here: the dependency could not
be avoided, because there is no additional dependency.

I opened <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689603> for this
some time ago.

> Maybe someone can check too why -pthread and -lrt is needed. I don't see a 
> reason here.

-pthread might well be specifically needed to allow dlopen() to load
GLib things into previously non-threaded processes:

    # NB: do NOT use -Wl,--as-needed to build glib; for instance the link to
    # pthread is carefully crafted to allow dlopen()ing pthread-using libs; see
    # http://mid.gmane.org/1257999019.21780.15.camel@marzipan
    LDFLAGS += -Wl,--no-as-needed

(<http://article.gmane.org/gmane.comp.gnome.gtk+.devel.general/18117> is
another route to the same mail.)

I don't know about -lrt; that one might be unnecessary.

Again, these do not actually cause any extra dependencies: libc, librt
and libpthread are all part of libc6 (or libc6.1 or libc0.1, if that's
where the architecture's libc is kept).

In practice I think this is wontfix for Debian's GLib maintainers; tagging
accordingly. If you would like this to be changed upstream, please discuss
it upstream (in GNOME).

    S