On Sat, Jun 05, 2010 at 10:29:57AM +1200, Richard Toohey wrote:
quoted text
> 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."

-- 
jakemsr@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org