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

[Yar Tikhiy]

On Wed, Aug 29, 2007 at 10:03:41AM -0400, Daniel Eischen wrote:
> 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.

I'm afraid the ld trick won't work because the error is from as(1),
e.g.:

: $ make
: cc -O2 -fno-strict-aliasing -pipe   -c foo.c
: {standard input}: Assembler messages:
: {standard input}:4: Error: multiple versions [`foo at FBSD_1.1'|`foo at FBSD_1.0'] for symbol `foo0'
: *** Error code 1

: $ cat foo.c
: #include <sys/cdefs.h>
: 
: int
: foo0(int n)
: {
:         return (n + 1);
: }
: 
: __sym_compat(foo, foo0, FBSD_1.0);
: __sym_compat(foo, foo0, FBSD_1.1);
: 
: int
: foo(int n)
: {
:         return (n + 3);
: }

Did I do anything wrong?

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

For the beginning, version_gen.awk could just complain about
duplicated symbols and suggest adding them to ObsoleteVersions as
there shouldn't be any duplicates in the whole version map generated.
Is that reasonable?  BTW, what is a good place for ObsoleteVersions?
src/lib/${libname}, along with Versions.def?  Or next to Symbol.map?

-- 
Yar