Re: Neat gtk/gdk-imlib pain
Jason Gunthorpe <firstname.lastname@example.org> 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
I haven't tested that it would actually work this way, so take this
idea with a grain of salt.