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

[Daniel Eischen]

On Fri, 24 Aug 2007, Yar Tikhiy wrote:

> On Fri, Aug 24, 2007 at 11:03:12AM -0400, Daniel Eischen wrote:
>> On Thu, 23 Aug 2007, Yar Tikhiy wrote:
>>
>>> yar         2007-08-23 05:09:31 UTC
>>>
>>> FreeBSD src repository
>>>
>>> Modified files:
>>>   lib/libc/gen         fts-compat.c fts-compat.h
>>> Log:
>>> Forced commit to note repo-copy:
>>>
>>> These files have been repo-copied from src/include/fts.h
>>> and src/lib/libc/gen/fts.c to serve as a base for 4.4BSD
>>> compatible versions of fts(3) functions to be preserved
>>> through libc symbol versioning while the default versions
>>> undergo ABI-breaking extension to support big file trees.
>>
>> When are you going to break the ABI?  After 7.0 is tagged
>> and released?  If you break the ABI before, you don't need
>> or want to have the compat versions; the libraries have already
>> been bumped in prep for release.  I don't think we want to
>> use symbol versioning as a crutch for -current users; the
>> version definitions are meant for public releases only.
>
> The reason for exercising symbol versions right now is that "make
> installworld" is sensitive to the fts(3) ABI.  If the ABI is just
> broken w/o special measures, "make installworld" will fail in the
> middle and leave you with a botched system.  It goes as follows:
>
> - "make installworld" copies the old /usr/bin/find and some other
>  tools to /tmp/install.xxx for use during the install
> - libc is overwritten by its new instance, with new fts(3) ABI
> - the old find(1) is run by installworld and dumps core immediately.

Why don't you make find and the install tools static.

> Earlier the problem was to be avoided by bumping libc version so
> that the old libc is kept, and now I chose symbol versioning to get
> around it.  Do you think there is a different way?

Yes, you wait until after release to do this.  Look at it
this way: if there wasn't symbol versioning and libc was
already bumped, how would you solve the problem?  You
wouldn't bump libc again, right?

-- 
DE