Re: Symbol versioning conventions (was Re: cvs commit: src/lib/libc/gen ...)

From: Daniel Eischen <deischen_at_freebsd.org>
Date: Tue, 28 Aug 2007 12:52:51 -0400 (EDT)
On Tue, 28 Aug 2007, Yar Tikhiy wrote:

> On Sun, Aug 26, 2007 at 12:48:41PM -0400, Daniel Eischen wrote:
>>
>> Here it is on -current, feel free to redirect it to arch.
>>
>> I updated my notes on symbol versioning - see "Version naming conventions"
>> on downwards at:
>>
>>   http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt
>>
>> Feel free to cut&paste anything from it in replies.
>
> It seems that we've failed to divert the main discussion from the
> cvs lists, so I'll comment on other sides of the symbol versioning
> issue.
>
> First, you wrote that a symbol having multiple versions needs to
> be listed in the symbol map file under each of its versions.  I'm
> afraid that the GNU ld(1) documentation doesn't suggest that.  I
> believe that it is correct to list each symbol in the symbol map
> only once, under its default version.

Ok, I'll update it.  I think that part of my notes was written
a long time ago.

> Second, we need to decide how to handle SV consistently at source
> tree level.  In a trivial case, cut'n'paste or a stub function will
> do, but in the more complex case of massive changes it can be hard
> to reproduce the old ABI using stubs, e.g., because the new
> implementation lost old bugs.  In this case, CVS history should be
> preserved for the old version at file level.  A uniform approach
> can be to repocopy the respective file(s) and add the version to
> their name(s), e.g.: fts.c -> fts_fbsd_1_0.c.  Does it sound
> reasonable?

Sure, I don't know if you have to use the version namespace in
the filename, though.  You could always put compat shim files
into a separate directory too, but that might make building them
a little more difficult if they rely on local headers.

-- 
DE
Received on Tue Aug 28 2007 - 14:53:13 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:16 UTC