Re: libgailutil.so.16 -> libgailutil.so.17

[textshell neutronstar dyndns org]

On Sat, Jul 27, 2002 at 10:36:38AM -0400, Owen Taylor wrote:

> First, a general comment on symbol versioning:
> 
> ELF symbol versioning is over-hyped.
> 
> Canonical example of symbol versioning is that the C library wants
> to change the size of 'struct stat', so you have a symbol 
> stat NEW VERSION that operates on the new stat structure
> which new apps use, and old apps still use the old version
> of stat().

This an example of a GNU extension over the sun scheme.
Hmm, all comments are from information from 
http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/index.html
I think this document is a nice description of the ELF versioning

> 
> So, what happens if a library (not the C library) uses 'struct stat'
> somewhere in it's interface - it has a 
> my_virtual_stat(struct stat *statbuf) if a newly
> compiled app uses an older copy of the library - the new app
> will expect the new stat structure, the old library the old
> stat structure. 
> 
> s/struct stat/GtkWidget/ and you see why symbol versioning just
> isn't practical for an object oriented library.
> 

Very good argument to ignore this part of the elf versioning.

> Avoiding compatiblity problems is real simple:
> 
>  - Make everything as opaque as possible
>  - Add padding where it makes sense
>  - Just don't make incompatible changes.
> 
> Where I think some symbol versioning tricks might be possible
> is something like Pango's relationship to FreeType -- Pango
> uses internal interfaces in FreeType, so I'd like to
> be able to say:
>  
>  libpango.so depends on libfreetype.so.6
>  libpango.so depends on libfreetype.so.6(INTERNAL_API.v653)
> 
> So package tools (etc.) could figure out dependencies without
> forcing a change in FreeType's main soname.
>