Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Aug 2007 12:52:51 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
To:        Yar Tikhiy <yar@comp.chem.msu.su>
Cc:        Ken Smith <kensmith@cse.Buffalo.EDU>, current@freebsd.org, "M. Warner Losh" <imp@bsdimp.com>
Subject:   Re: Symbol versioning conventions (was Re: cvs commit: src/lib/libc/gen ...)
Message-ID:  <Pine.GSO.4.64.0708281249190.3757@sea.ntplx.net>
In-Reply-To: <20070828140331.GA598@comp.chem.msu.su>
References:  <20070824.172212.74696955.imp@bsdimp.com> <Pine.GSO.4.64.0708242252520.15344@sea.ntplx.net> <20070825053302.GG99474@comp.chem.msu.su> <20070825.093925.43008968.imp@bsdimp.com> <1188071752.1853.44.camel@neo.cse.buffalo.edu> <Pine.GSO.4.64.0708251703550.19091@sea.ntplx.net> <20070826073535.GD21352@comp.chem.msu.su> <Pine.GSO.4.64.0708261240070.23191@sea.ntplx.net> <20070828140331.GA598@comp.chem.msu.su>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0708281249190.3757>