Symbol versioning conventions (was Re: cvs commit:
src/lib/libc/gen ...)
Daniel Eischen
deischen at freebsd.org
Tue Aug 28 09:53:13 PDT 2007
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
More information about the freebsd-current
mailing list