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 (granted, GObject or
gpointer aren't likely to change incompatibly, but I'm sure you can find
other examples where changes are more likely).
Saludos,
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
