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

[Daniel Eischen]

On Wed, 29 Aug 2007, Yar Tikhiy wrote:

> On Tue, Aug 28, 2007 at 04:15:16PM -0400, Daniel Eischen wrote:
>> On Tue, 28 Aug 2007, John Baldwin wrote:
>>
>> 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.

I think you can use -z muldefs or --allow-multiple-definition as a
linker argument to work around that.  libpthread once did that (or
something like it) so it could be compatible with libpthread.so.1
which used LIBPTHREAD_1_0 instead of FBSD_1_0.

> 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.

When someone changes the ABI, he's going to add a new set of symbols
to a Symbol.map file.  At this point before he commits he should
notice that there are duplicated symbols.  If he does, then he
removes them and updates ObsoleteVersions.  If he doesn't, then
you have duplicate symbols ;-)  Or you just have a script that
does this for you (version_gen.awk might be a good starting
point!).

-- 
DE