Date: Thu, 28 Aug 1997 10:39:10 +0930 From: Greg Lehey <grog@lemis.com> To: Wes Peters <softweyr@xmission.com> Cc: questions@freebsd.org Subject: Re: Any reason not to remove /usr/obj/* ? (fwd) Message-ID: <19970828103910.42694@lemis.com> In-Reply-To: <199708261425.IAA21981@obie.softweyr.ml.org>; from Wes Peters on Tue, Aug 26, 1997 at 08:25:24AM -0600 References: <Pine.BSF.3.96.970825230501.21041A-100000@andrsn.stanford.edu> <19970826160248.15087@lemis.com> <199708261425.IAA21981@obie.softweyr.ml.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 26, 1997 at 08:25:24AM -0600, Wes Peters wrote: > Oh so recently I blathered: >> In short: if you've got the disk space and are going to be rebuilding >> the world, leave 'em. If you need the disk space, grab it. If you're >> undecided, buy a Jaz drive and a cartrige for /usr/obj. ;^) > > Greg Lehey elaborated thusly: >> That depends on how you make your world. Normally, the first thing >> that 'make world' does is to remove all the objects and start afresh. >> Check /usr/src/Makefile: > > Thanks for pointing this out; I realized I have several make environment > variables I set in my root account that gives me the behavior I > espoused. Yes, indeed, the standard 'make world' target starts off with > a 'make clean'. In this case, and empty /usr/obj will probably speed up > the make process somewhat. > > My environment variables automagically run make with -DNOCLEAN, which > speeds up the make world somewhat, but can lead to catastrophic > failures. The remedy in this situation is to boot into single user, > mount up your normal disks, and run a regular 'make world.' Not > something you'd want to do on a production machine, but this is my own > workstation, right? Indeed. For those who are tracking -current, you may have run into the same problem that has been driving me mad this past week: if I do a 'make world' and remove the /usr/obj tree, the make runs fine. If I run my standard nightly build job, which does a -DNOCLEAN, it screws up the file /usr/lib/libc.so.3.0, the standard dynamic C library. The result is that the system effectively hangs when the file is installed. The kernel's still running, but running processes die, and you can't start any more. I have a spare file in /usr/lib which I can move into place, assuming that I can get a shell to run, but as Bill says, that's not everybody's taste. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970828103910.42694>