cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h

[John E Hein]

Yar Tikhiy wrote at 09:33 +0400 on Aug 25, 2007:
 > On Fri, Aug 24, 2007 at 11:08:01PM -0400, Daniel Eischen wrote:
 > > 
 > > It should be easy to say FBSD_1.0 is RELEASE_7.0, FBBSD_1.1 is RELEASE_7.1,
 > > etc.  The versioned symbol namespace is mostly to aid the release
 > > engineers.  If you start to have FBSD_1.2, FBSD_1.3,  and FBSD_1.4
 > > are interim versions and FBSD_1.5 is release 7.1, that isn't good.
 > 
 > In addition, symbol versions are mere text labels with no special
 > meaning to ld(1), so we can format them to allow for version changes
 > between major releases.

By way of precedent, this reminds me of how __FreeBSD_version is used
for miscellaneous intra-release changes (changes that aren't
necessarily ABI changes, but perhaps disappearance or emergence of new
tools or tool changes).  For instance, this has been known to happen
when the pkg* tools change and the ports infrastructure is tweaked to
behave differently based on the fine-grained FreeBSD version (aka
OSVERSION).

Can the symbol versioning labels be standardized to make similar
accomodations for ABI changes in between releases?

Even in stable branches, now that I think about it.  I almost removed
that controversial thought from this email to avoid a flame war.  But
on the other hand, used conservatively, I could foresee a security fix
being made much easier if an ABI change was allowed.  This would be
quite rare, I'm sure.