On Sat, Jun 05, 2010 at 10:29:57AM +1200, Richard Toohey wrote: > On 5/06/2010, at 7:31 AM, Nick Holland wrote: > > > Jacob Meuser wrote: > >> On Fri, Jun 04, 2010 at 04:22:35PM +0000, Uwe Dippel wrote: > >>> Still, may I suggest, that the next Upgrade Guide gets an extra line, with > a > >>> remark pointing out the existence of /usr/obj; and the suggestion to clean > it? > >> you can't supply a patch? can't even attempt one? all these posts and > >> time wasted and you can't try to make a patch to maybe save someone else > >> from the same fate? > > > > a patch to the upgrade guide would be wrong. > > > > The problem is the patching process (a special case of the userland build > process) assumes a clean obj dir. This has nothing to do with upgrades. If > you try to rebuild the same userland utility more than once for /any/ reason > without clearing the obj dir, you can run into problems. Clearing the obj > directory as part of the upgrade is like flushing your toilet based on the > date -- may help, but after a while, things start to stink. It isn't the > general (or proper) solution. > > > > faq10.html, section 10.15 would be more appropriate, I think. It will > probably require more than a couple line diff to work it in clearly. > > > > Nick. > > > > So something in or around here ... > > "Not all patches are for the kernel. In some cases, you will have to rebuild > individual utilities. At other times, will require recompiling all utilities > statically linked to a patched library. Follow the guidance in the header of > the patch, and if uncertain, rebuild the entire system." > > Along the lines of: > > "In some cases (you'll know you have do this because xxxxx) you need to clean > /usr/obj first, you do this by yyyyy." > > Let me learn what xxxxx and yyyyy are. > > Thanks.
I'm still curious how anything left in /usr/obj can be anything but a possible problem after updating system binaries and sources to a new release. especially for people who are just "following the directions as they are written." -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
