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

[Yar Tikhiy]

On Tue, Aug 28, 2007 at 04:15:16PM -0400, Daniel Eischen wrote:
> On Tue, 28 Aug 2007, John Baldwin wrote:
> 
> >On Tuesday 28 August 2007 01:18:38 pm Daniel Eischen wrote:
> >>
> >>The only thing I would add is that we can do this by using the
> >>real public versions in -current instead of private ones only
> >>seen in current.  By using the public versions, -current users
> >>will never have to rebuild any of their ports _unless_ the
> >>same ABI changed more than once in -current, and that has
> >>never happened in the past.  If it does happen, you can
> >>remove interim versions from RELENG_X at the branch, and
> >>then remove the interim version from -current some time later.
> >>This is the same approach as using a "private in current"
> >>version namespace.  The only disadvantage is that you might
> >>be missing a version or two in RELENG_X if you remove an
> >>interim FBSD_1.4 for instance.
> >
> >Yes, but how do you know which ones are interim versions that are safe to 
> >be
> >removed?  Having separate namespaces makes this clear.
> 
> Any symbol in the Symbol.map files (or the generated Version.map)
> that is duplicated from the point at which -current was last
> branched.
> 
> If you go with my approach and only create one new version in
> -current, then it will be more obvious because the symbol(s)
> will already exist in -current's one and only version.  That
> will force us to decide whether we should force a rebuild or
> just make a new version - it could be on a case by case basis
> if it ever happened.
> 
> But even with the other approach (each ABI change creates a
> new version), you could write a script to find all the versions
> with duplicate symbols.  I suppose you could even have it
> generate an ObsoleteVersions file that gets committed along
> with the most recent ABI change.

At this point we should consider technical limitations as well.
I think I found a couple, unfortunately.

On the one hand, John's approach depends on alias symbols in HEAD
so, e.g., both foo at FBSD-1.9 (public) and foo at FBSD-current-1.8.5
(interim) can point to the same implementation for the "foo" interface
after STABLE with foo at FBSD-1.9 was branched.  However, the GNU build
tools don't seem to provide a straight way to that, they return an
error if multiple versions reference the same function, so more
stub code will be needed in the library, which will add to complexity
of the approach.

On the other hand, Symbol.map files should not contain duplicate
symbol names as it seems to violate ld(1) semantics.  Therefore,
if following Daniel's way, we'll need to track which symbols moved
by more than one version since the last STABLE branch to find interim
versions.  This shouldn't be too hard, but the implementation details
are somewhat different.

-- 
Yar