On Fri, 2009-11-13 at 03:53 +0100, nf2 wrote: > On Thu, Nov 12, 2009 at 7:52 PM, Alexander Larsson <al...@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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list