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, 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>