No libc shared lib number bump ?
Yar Tikhiy
yar at comp.chem.msu.su
Fri Oct 19 01:48:23 PDT 2007
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
More information about the freebsd-current
mailing list