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

[Yar Tikhiy]

On Tue, Sep 04, 2007 at 03:14:00PM +0400, Yar Tikhiy wrote:
> On Thu, Aug 30, 2007 at 04:38:57AM -0400, Daniel Eischen wrote:
> > 
> > Hmm, I guess it's not that simple.  Take a look at the hack I had to make in
> > libpthread/thread/thr_private.h (line ~67).  I had to create weak references
> > to the functions, so for your example, you'd need something like:
> > 
> > __weak_reference(foo0, foo0_10);
> > __weak_refefence(foo0, foo0_11);
> > __sym_compat(foo, foo0_10, FBSD_1.0);
> > __sym_compat(foo, foo0_11, FBSD_1.1);
> > 
> > I think I also needed to make the latest symbol the default, changing
> > the last line above to __sym_compat_default(foo, foo0_11, FBSD_1.1),
> > but I seem to recall earlier email from you saying this shouldn't
> > be needed.  I _think_ I needed to for libpthread, but perhaps that
> > is because I had the symbols (e.g. foo) listed in both sections of
> > the map file:
> > 
> > 	LIBPTHREAD_1_0 {
> > 		pthread_foo;
> > 	};
> > 
> > 	FBSD_1_0 {
> > 		pthread_foo;
> > 	};
> > 
> > See r.19 of libpthread/pthread.map.
> 
> Just tried this trick, and, alas, it didn't really help.  Namely
> it helped to make the library buildable, but not all alias versions
> of the symbol ended up in it.  I tested various combinations of the
> __weak_reference, __sym_compat, and __sym_default directives in
> conjunction with different symbol maps listing the symbol under one
> or many versions.  The result was the same: only one alias version
> was in the library and available to apps linked against it, while
> the other was absent.

I must withdraw my argument against alias versions.  My problem
with them appeared to stem from a typo in "__weak_reference" I'd
inherited from your example. :-)
It's funny that the compiler emitted just a vague warning:

foo.c:12: warning: data definition has no type or storage class
foo.c:12: warning: parameter names (without types) in function declaration

and the typo remained unnoticed until I saw it by accident.

Now I'll investigate if macros can help us to have right versions
in branches and HEAD...  Do you think there is a non-hackish way
to see if we're on a STABLE branch?  __FreeBSD_version doesn't seem
to provide the information until after the first release from the
branch has been cut.

OTOH, we should't dump ObsoleteVersions completely because we may
need it, too, e.g., when we didn't plan to break an ABI twice in a
row but have to.

-- 
Yar