Re: ->

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
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:
> depends on
> depends on
> So package tools (etc.) could figure out dependencies without
> forcing a change in FreeType's main soname.

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