Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Aug 2007 20:09:16 +0400
From:      Yar Tikhiy <yar@comp.chem.msu.su>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        src-committers@freebsd.org, jhb@freebsd.org, peterjeremy@optushome.com.au, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, eischen@vigrid.com, kensmith@cse.buffalo.edu
Subject:   Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h
Message-ID:  <20070827160916.GN21352@comp.chem.msu.su>
In-Reply-To: <20070827.085906.-332187760.imp@bsdimp.com>
References:  <Pine.GSO.4.64.0708251703550.19091@sea.ntplx.net> <1188077596.1853.55.camel@neo.cse.buffalo.edu> <200708270932.31208.jhb@freebsd.org> <20070827.085906.-332187760.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 27, 2007 at 08:59:06AM -0600, M. Warner Losh wrote:
> In message: <200708270932.31208.jhb@freebsd.org>
>             John Baldwin <jhb@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



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