Date: Tue, 4 Sep 2007 17:21:16 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: arch@freebsd.org Subject: Re: ABI and install tools (was Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h) Message-ID: <20070904132116.GS30502@comp.chem.msu.su> In-Reply-To: <20070828014748.GV21352@comp.chem.msu.su> References: <Pine.GSO.4.64.0708241819220.13181@sea.ntplx.net> <20070824.172212.74696955.imp@bsdimp.com> <Pine.GSO.4.64.0708242252520.15344@sea.ntplx.net> <20070824.213615.146406398.imp@bsdimp.com> <20070828005654.GA50401@dragon.NUXI.org> <20070828014748.GV21352@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 28, 2007 at 05:47:49AM +0400, Yar Tikhiy wrote: > [Redirecting this branch to -arch] > > On Mon, Aug 27, 2007 at 05:56:54PM -0700, David O'Brien wrote: > > On Fri, Aug 24, 2007 at 09:36:15PM -0600, M. Warner Losh wrote: > > > In message: <Pine.GSO.4.64.0708242252520.15344@sea.ntplx.net> > > > Daniel Eischen <deischen@freebsd.org> writes: > > > : I guess the build system should be more tolerant of this, but > > > : there are bound to be problems regardless. I don't see why > > > : the install tools can't also either have their own set of > > > : libraries (utilizing LD_LIBRARY_PATH) or be built static. > > > > > > There's much resistance to building everything that the build system > > > might be used being build static. It adds too much time and > > > complexity to the build system, the opponents say. > > > > I've never heard an argument against building these bits static. > > What's the issue? > > FWIW, here's a patch implementing the opposite approach: If we're > going to install world over this system (installworld with DESTDIR > unset or empty), first install the new versions of necessary tools > to a scratch directory and then switch to the new tools. The kernel > must be capable of running the new tools with the new libraries, > which is an already existing requirement. > > With the patch, the build system can tolerate ABI breakage in libc > and, according to audit(4), it runs no binaries from the old system > in the sensitive part of installworld. > > For easier and safer testing, INSTALL_TESTING can be set so that > the new way is chosen even if DESTDIR is set. Of course, make sure > that the new tools are for the same platform as the machine runs. > Usually you cannot select a different platform w/o setting DESTDIR. > > Comments are welcome. Thanks! For the record: Ruslan Ermilov has objected privately to the proposed approach with quite reasonable arguments, the most important one being that using new binaries if DESTDIR is unset would mean using different tool sets for different install types, which will make debugging other people's installworld problems harder. Therefore we've started to work on the opposite approach, i.e., saving old libs along with old tools for installworld to use. It has proved rather elegant and not depending on any ifs, unlike the former approach. And, with an extra bit of magic around ld.so, it allows for installing world built for a different arch, e.g., amd64 over i386, which is fun. :-) The current state of the task can be seen there: http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/user/yar/hack/Makefile.inc1 -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070904132116.GS30502>