Re: No libc shared lib number bump ?

On Thu, Oct 18, 2007 at 01:19:50PM +0400, Andrey Chernov wrote:
> On Thu, Oct 18, 2007 at 09:25:55AM +0200, Kris Kennaway wrote:
> > Thierry Herbelot wrote:
> >> Hello,
> >> I just saw on my -current box that some/most/all shared libraries seem not 
> >> to have been bumped when REL_7 was branched :
> >> % ll /lib/libc.so*
> >> -r--r--r--  1 root  wheel  1036012 Oct 15 23:33 /lib/libc.so.7
> >> % uname -a
> >> FreeBSD YYY 8.0-CURRENT FreeBSD 8.0-CURRENT #1919: Wed Oct 17 20:39:59 
> >> CEST 2007     XXX_at_YYY:/tank/files3/obj/tank/files1/src/sys/GENERIC  i386
> > 
> > This is deliberate, there is no longer any need now or in the future (since 
> > symbol versioning now exists).
> 
> I don't understand this thing well, since it is new. Is there some 

First of all, I'd recommend the original GNU ld documentation page on
version script format and semantics:

http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html

Our own implementation is just a simple frontend to that.

> howto's in symbol versioning exists for most common cases like that:
> a) some new function/variable/struct added
> b) some existen function/variable/struct changed
> (at this moment I am interesting especially in a) case since did it for 
> ctype)

The technical side is covered well by the document by Daniel, and
the essence of the policy we've finally outlined is rather simple:
Make your best to ensure that the new versions of individual symbols
you introduce in HEAD make it to the next major release.  The
background behind it is that ideally each and every version of a
symbol introduced to a library will stay in it forever, thus adding
more support overhead for the security team etc.  Therefore it may
be unwise in the long run to introduce versions that never see a
release.

Yar