Re: Neat gtk/gdk-imlib pain
On 1 Feb 1999, Jim Pick wrote:
> 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
Erm, but that doesn't make any sense in the context of glibc! glibc2.1 is
NOT a unique soname but is simply a glibc2.0 with changes. Somehow the
symbol versioning is used to tell '2.1 special' programs apart from '2.0
special' programs and 'do the right thing' You don't need to have two
libcs.
> I haven't tested that it would actually work this way, so take this
> idea with a grain of salt.
The trouble with that sort of simple view is that it assumes that you can
freely mix the new features from a new libgtk with the old features from
an old gtk in such a way as to not create caos and destruction, I don't
think that can be done without alot of carefull planning.
Jason
Reply to: