Re: GDBus in gio? [was Re: Minutes of the GTK+ Team Meeting - 2009-11-10]

[Alexander Larsson <alexl redhat com>]

On Fri, 2009-11-13 at 03:53 +0100, nf2 wrote:
> On Thu, Nov 12, 2009 at 7:52 PM, Alexander Larsson <alexl redhat com> wrote:
> > On Tue, 2009-11-10 at 18:22 -0600, Stef Walter wrote:
> >> Emmanuele Bassi wrote:
> >> > 1. bug 600141 (desrt)
> >> > - dbus-1 brings in pthread
> >> > - gio-2.0 doesn't
> >> > - dlopen()-ing a shared object linking to pthread from a library
> >> >   that doesn't is a big no-no which kind of works in Linux but
> >> >   breaks things like gdb
> >> > - big hammer: make gio-2.0 depend on gthread-2.0
> >> > - small hammer: make gio-2.0 pkg-config file include -pthread
> >> > ACTION: desrt should involve gtk-devel-list and gather feedback
> >>
> >> Is there a reason the dbus stuff won't become its own glib module along
> >> side gio, gobject, gthread etc...?
> >
> > Well, gio would still need to link to this so all gio apps still pull it
> > in. Additionally there is a non-negligible overhead for each library
> > linked into an app (due to elf linking rules), so the extra library is a
> > performance loss for all applications.
> >
> 
> Is the order of libraries reported by ldd also the one the linker uses
> for looking up symbols?
> 
> So if for instance (simplified) Gtk needs to look up a lot of symbols
> from X11, many from GObject and GLib, but few from GIO and others,
> wouldn't it be more promising to get the ordering right (rather than
> scaling down on modularity)?

I'm not sure exactly which order the libraries are searched, as there
are multiple link-lines involved in the linking of an application (once
for the app and once for each linked in library).

However, playing with link order is problematic because on other
(non-ELF) systems linking requires that each thing listed on the command
line only depends on things listed to the right of it. So -lfoo -lbar
may fail to link if libbar references libfoo symbols.