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

[Yar Tikhiy]

On Mon, Aug 27, 2007 at 08:59:06AM -0600, M. Warner Losh wrote:
> In message: <200708270932.31208.jhb at freebsd.org>
>             John Baldwin <jhb at freebsd.org> writes:
> 
> : Yar's changes should go in and before BETA1, but we don't need any compat
> : hacks because the compat would be for users that we don't provide compat
> : for.
> 
> ALL of Yar's changes should go in, including the versioned symbols.
> Since the consequences of this ABI breakage are trivial to mitigate
> with symbol versioning, we should do so.  We need a dry-run at it to
> make sure there are no problems in the process.  We also should not
> force all our testers right now to go through significant pain and
> suffering.  They are much less likely to upgrade and continue to test
> out new versions of current.  Rebuilding all the ports (since it is
> hard to know which ones use fts) is hard and time-consuming (even on
> my fast machines it takes days to rebuild everything exclusive of
> ooo).

Although I can appreciate the arguments of Daniel and John now,
[thank you John! :-)], this is also a very valid point to consider.
I hate to mention it, but symbol versioning appeared literally
non-functional due to a bug in the map-generating script when I
tried to use it for the first time in the course of the fts(3)
hustle.

> In short, I think this is the easiest solution to the build problems
> that the change will cause given the set of users that are presently
> using the head of the tree.  Hacking the build system to make the
> incompatible change is dangerous and may break other upgrade paths
> that are working.  Giving users explicit instructions for jumping the
> gap would fix the intallworld case, but would still force users to
> rebuild all their ports.  Adding the versioned symbols introduces a
> tiny bit of cruft in the purity of the ABI, but solves the
> installworld problem AND the rebuilding the ports problem.  Are there
> other REAL solutions to the problem I've not considered?

I hope I've found a clean way to overcome the problem in our build
system.  The problem stemmed from using basic tools from the old,
pre-installworld system during installworld.  The tools were copied
just in case to a scratch directory, so it isn't hard to install
the newly built versions of the same tools there instead and make
them load the new shared libraries available under ${WORLDTMP}.
The trick depends on the running kernel being able to run both old
and new code, but it's a well-known requirement for installworld
over the live system.  I'm going to post the patch for review soon.

-- 
Yar