On Thu, Sep 10, 2009 at 12:35:12AM +0200, Kurt Roeckx wrote:
> 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.
And it will probably require a _lot_ of code to be kept around for lots
of time. At best compatibility layers, and worst case, pure duplication
of all APIs.
symbol versioning is really nice, but it's not magic either ;)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
signature.asc
Description: Digital signature