On Wed, Aug 26, 2009 at 03:46:36AM -0400, Felipe Sateler wrote: > Steve Langasek wrote: > > > On Wed, Aug 26, 2009 at 02:08:40AM -0400, Felipe Sateler wrote: > >> But this will cause trouble anyway. Imagine this case: glib changes > >> SONAME, both app and library depend on glib. app is recompiled, gtk isn't > >> yet.So then app NEEDED libglib-2.0.so.1, gtk NEEDED libglib-2.0.so.0. > >> Kaboom! The only real solution is to make gtk's SONAME dependent on > >> glib's, eg libgtk- x11-2.0.so.0-glib-1 (a la boost upstream with gcc > >> versions). > > I think I should have added that the app does not have to link directly with > glib. > > > > > That's what symbol versioning is for. > > >From /u/i/g/g/gtktextchild.h: > > struct _GtkTextChildAnchor > { > GObject parent_instance; > > gpointer GSEAL (segment); > }; > > You lost anyway. If GObject or gpointer changes, symbol versioning doesn't > save you because _GtkTextChildAnchor is a public type
This can all be solved using symbol versioning. Buf it will probably require alot of work to get it right. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org