Re: Neat gtk/gdk-imlib pain

[Jim Pick <jim@jimpick.com>]

Jason Gunthorpe <jgg@ualberta.ca> writes:

> On 1 Feb 1999, Jim Pick wrote:
> 
> > > Ideally the devel GTK/etc -should- co-exist with the stable stuff, if it
> > > doesn't then I think that is a serious problem. I can tolerate apps from
> > > potato breaking left and right, but old apps from slink? Bleck.
> > 
> > I'm becoming more convinced of the need for symbol versioning.
> 
> I'd be pleasently surprised if versioning could fix the gtk/glib/gnome
> problems, but I think it's role is more to deal with minor corrective
> drift that whole scale mutually incompatible changes. I mean if gtk1.1 and
> gtk1.0 are not even source compatible it is crazy to think symbol
> versioning will do anything to help them. 

Here's how I think it works:

  Pretend that wmakerconf was linked with an imlib that used a
  hypothetical libgtk1.1.20.  So symbol gtkfoo from libgtk1.1.20 would
  be referred to in wmakerconf like so:

  $ objdump --dynamic-syms /usr/X11R6/bin/wmakerconf | grep foo
    0003cea0 g    DF .text  00000018  GTK_1.1.20   foo

  If a new imlib came along that was linked with the incompatible
  libgtk1.1.21, the dynamic linker would examine both
  /usr/lib/libgtk-1.1.so.20 and /usr/lib/libgtk-1.1.so.21 (based on
  the soname search, like the present situation).  However, instead of
  binding to the first symbol it found, it would only bind to the foo
  symbol in /usr/lib/libgtk-1.1.so.20

  If you ran a new program linked against the newer imlib and gtk,
  it's symbol gtkfoo would look more like:

  $ objdump --dynamic-syms /usr/bin/new-gtk-program | grep foo
    0004dea0 g    DF .text  00000018  GTK_1.1.21   foo

  Naturally, this symbol would get bound to the foo symbol in
  /usr/lib/libgtk-1.1.so.21

I haven't tested that it would actually work this way, so take this
idea with a grain of salt.

Cheers,

 - Jim