RFC: Symbol versioning for libc

I've been working on symbol versioning libc and have a patch
that seems to work.  It's been tested on x86 with build &
install world, KDE, mozilla, and firefox, but there may be
some problems I haven't found yet.  These would likely result
in undefined symbol errors from libraries or applications.

I'd like to commit what I have to enable wider testing, but
turn off symbol versioning by default.  I would also like
re_at_ to take a look at the version namespace scheme.  The
following was derived from Sun's convention.

    FBSD_1.0 (FBSD_X.Y[.Z])
        This is the first rev of the public namespace for
        libc and related libraries.  For every minor
        release of FreeBSD, starting with 7.0, the minor
        version of the namespace will be bumped if there
        is an ABI change.  The version is bumped as soon
        as the first ABI change hits the tree.  If there
        are no ABI changes, a minor-minor (subminer?)
        version (Z) can be added (or bumped) to denote a
        release, performance improvement, etc.

    FBSDprivate_1.0 (FBSDprivate_X.Y)
        This is our private namespace.  Any symbols that
        need to be visible outside of libc (or any other
        versioned library) that are only meant for use by
        our own libraries or applications are listed in
        this namespace.  For instance, _spinlock() which
        is overridden in libc by the thread libraries, or
        libc's __pw_scan() or __use_pts() which are used
        by libutil.  This is initially given a version
        number, but is not bumped after introducing private
        ABI changes or within release cycles.  We provide
        a complete system built from a consistent set or
        sources, so there is no real need to maintain
        ABI in this namespace.  However, since our first
        release may need to be compatible with older libraries
        built before symbol versioning, it may require us
        to provide at least one additional version.

The two namespaces allow us to write simple ABI-checking
tools (readelf -s application | grep "FreeBSDprivate") that
3rd-party developers can use to certify compliance with our
ABI.  We (FreeBSD) will give no guarantees about anything
within the FreeBSDprivate version namespace; symbols within
that namespace may come and go within release cycles.

The proposed numbering scheme would be something along the
lines of this (in linker map format and in chronological order):

  # Release 7.0
  FBSD_1.0 {
  };
  FBSDprivate_1.0 {
  };

  # Release 7.1 - no ABI changes, depends on FBSD_1.0
  FBSD_1.0.1 {
  } FBSD_1.0;

  # Release 7.2 - with ABI changes, depends on FBSD_1.0
  # There is no benefit to depending on 1.0.1 since there
  # are no ABI changes to inherit.
  FBSD_1.1 {
  } FBSD_1.0;

  # Release 8.0 - with or without ABI changes
  # This was branched from release 7.2.  It could just as
  # well have been branched from 7.0 or 7.1.
  FBSD_2.0 {
  } FBSD_1.1;

  # Release 7.3 - without ABI changes, depends on FBSD_1.1
  FBSD_1.1.1 {
  } FBSD_1.1;

  # Release 7.4 - with ABI changes, depends on FBSD_1.1
  FBSD_1.2 {
  } FBSD_1.1;

  # Release 8.1 - with ABI changes, depends on FBSD_2.0
  FBSD_2.1 {
  } FBSD_2.0;

  ...

The latest patch is here:

  http://people.freebsd.org/~deischen/symver/symver.diffs.030706

There's a brief description of symbol versioning here:

  http://people.freebsd.org/~deischen/symver/library_versioning.txt

and you can find some other documents at:

  http://docs.sun.com/app/docs/doc/817-1984
  http://people.redhat.com/~drepper/symbol-versioning

or google.


-- 
DE