[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> 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.


Reply to: