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

John Baldwin jhb at
Mon Aug 27 10:36:28 PDT 2007

On Monday 27 August 2007 01:10:14 pm Daniel Eischen wrote:
> On Mon, 27 Aug 2007, John Baldwin wrote:
> >
> > Perhaps a more useful discussion would be how can we use symbol versioning
> > sanely to support this in the future?  The fbsd.hack idea could work, but
> > it doesn't work in this case because the existing binaries are already
> > linked.  One suggestion that could start with 8.0 could be this:
> >
> > - when bumping the version for a symbol in HEAD, instead of going from
> >  fbsd-X.Y to fbsd-X+1.0, put the new symbol as fbsd-current-X+1.0.  You
> >  can keep bumping the symbol as fbsd-current-X+1.whatever for subsequent
> >  changes
> > - when it's time to branch HEAD to RELENG_X+1, you then add fbsd-X+1.0
> >  symbol versions for the current versions of all the bumped symbols, and
> >  remove all the fbsd-current-* versions and compat shims before the
> >  release (before the RELENG_X+1_0 branch in fact).  The rule there being
> >  that no release should ever ship with visible fbsd-current-* symbol
> >  versions.
> I don't think you need intermediate symbol versions, one should be
> sufficient.  The problem would only arise if you make an ABI change
> to a function or set of functions that have already had an ABI change
> in the current version.  For example, if there were a function
> ftsfwrite(FTS, FILE *, ...), and you make the version bump from
> FBSD_1.0 to FBSD_1.1 when FTS changes, then if FILE changes, you
> need to bump FBSD_1.1 to FBSD_1.2.  If there are no overlapping
> changes in the ABI, you can continue to add newly changed symbols
> to the current version (in this case FBSD_1.1).

Actually, what we have now with fts(3) is exactly this: two versions of the 
symbols that wish to be called fbsd_1.0.  By using a late binding of 
the "official" fbsd_X.0 version we can avoid that.  It also provides a way to 
delineate ABI changes that aren't visible to releases and -stable branches.  
They will exist in HEAD with only having a fbsd-current symbol, so they can 
be axed from HEAD safely.

> How may times have we ever had overlapping ABI changes in the past?
> Have we ever?  It's not worth fiddling with intermediate symbols,
> because with that method you're still forcing -current users to
> rebuild everything just before or after RELEASE to get the final
> symbols (when the intermediates are removed).  If there are no
> overlapping ABI changes, then no one has to rebuild any ports.

You don't have to remove the compat shims from HEAD right away.  Remember, 
release is on a _branch_: RELENG_X.  You remove the compat shims from the 
branch before the release, but you can use discretion as to when you
actually remove them from HEAD.

John Baldwin

More information about the cvs-src mailing list