Re: Get rid of deprecated widgets

[Alexander Larsson <alexl redhat com>]

On Thu, 2007-12-06 at 19:04 +0200, Stefan Kost wrote:
> Hi,
> Xavier Bestel schrieb:
> > On mer, 2007-12-05 at 14:09 +0100, Alexander Larsson wrote:
> >> The only way to make this backwards compatible is to make
> >> libgtk-2.0.so.0 have the deprecated symbols and link to
> >> libgtk-no-compat-2.0.so.0 which doesn't. Then normal apps will keep
> >> working, and apps that don't need compat widgets will need to link with
> >> -lgtk-no-compat-2.0.
> > 
> > Each new releases may deprecate some symbols. So what's needed is a
> > symbolic library name per release, and say when you release gtk+2.14,
> > make libgtk-2.0.so ... libgtk-2.12.so all point to the same thing (with
> > all deprecated symbols) which then links to libgtk-2.14.so with only
> > supported symbols.
> 
> Removing the deprecated stuff is in most cases not an option. But lowering the
> impact is. WHat kind of impact have they?
> 
> 1) longer symbol resolving on startup

This is unlikely to be affected. There is one hash lookup per shared
object in the global namespace on each symbol resolve. The number of
symbols in a shared object should not affect things much, as the hash
table is just made larger.

> 2) memory usage

If its not used, should be little. It does affect paging behaviour of
the other code though, so some code/data rearrangement would probably
help a bit.

> 3) locatisation

All of this stuff is old, doesn't change and is already translated, so I
don't think its a huge problem.

> 2) can be addressed like i described in
> http://bugzilla.gnome.org/show_bug.cgi?id=471123

I added a comment to this, because I don't think the method described
will work as well as it can.

> Now it would be great if we could also tell the linker to resolve deprecated
> entries lazily. That would help with 1).

ELF symbols are always lazily resolved. Unless LD_BIND_NOW is defined
(on linux/gnu).

One can further reduce the costs of symbol lookups with prelink.