buildworld: don't know how to make iterator.cc
Jeremy Chadwick
freebsd at jdc.parodius.com
Sun Jan 22 05:32:05 UTC 2012
On Sun, Jan 22, 2012 at 02:14:44PM +0900, Randy Bush wrote:
> > Randy, when moving from one to another, are you deleting the contents
> > of /usr/src before doing the csup? More explicitly, this is what you
> > should do when going from one release to another:
> >
> > rm -fr /usr/src
> > rm -fr /var/db/sup/src-all
> > rm -fr /usr/obj/*
> > csup ...
>
> in a decade or more, i have never done the first two. but i ain't proud
> and will certainly try it now.
I need an actual developer to confirm my theories, but FWIW, I've given
people this advice many times over the years with general success.
The theory that I have is that since csup is basically based on CVS,
which is based heavily on version numbers, combined/intermixed with a
"database", what you end up with is this kind of situation:
Your /usr/src contents are, say, for RELENG_8.
/usr/src/some/Makefile is version 1.4.12.3.
/var/db/sup/src-all/checkouts.cvs:RELENG_8 contains a line for
src/some/Makefile that says it's version 1.4.12.3.
Now you come along and change your supfiles to refer to the release tag
of RELENG_9. The tag value itself doesn't matter; the point is that
it's different.
Then you do a csup. csup now makes a new CVS database file called
/var/db/sup/src-all/checkouts.cvs:RELENG_9 and begins populating this
file.
However, as it populates the file, it also (obviously) has to compare
version numbers to that of what's actually on your filesystem in
/usr/src.
csup then pulls down src/some/Makefile (for RELENG_9), where the version
number is different; say, version 1.14.3.0. Note that the version
number is not "higher" (larger) than the previous (1.14.12.3). Thus
/usr/src/some/Makefile doesn't get changed/modified.
csup finishes, you think everything is great, then you build world or
kernel which depends on /usr/src/some/Makefile. Depending on what the
actual differences are (between the two tag/release files), it may work,
and it may not. In the case of "it may not", it may be referring to
some object files or source files (or anything -- especially in the case
of a Makefile) that don't exist, didn't get created, etc. simply because
the Makefile (maybe somewhere else in the tree) didn't build what's
expected.
There's also another situation (different than above, but the resulting
problem can be the same) where if when installing the OS you choose to
install src and ports (from the CD/DVD media), then start using
csup/cvsup, things can get "out of whack".
This is covered in the cvsup FAQ, and is referred to as "adopting your
source", specifically Item #10 here: http://www.cvsup.org/faq.html
Then there's the other situation which pertains to a /usr/obj that still
contains created/data "stuff" (objects, etc.) for an old version/tag,
which an administrator forgets to COMPLETELY nuke/clear out before
building world/kernel after changing tags. You have to do that. There
is a "make" command in /usr/src that claims to do this, but it cannot be
reliably used when going between tags -- the reason is the same as above
(new files or old files introduced may not get removed).
As such, for all of these situations, the recommendations I have given
others and have followed for years (with 100% success rate for me
anyway) is:
1. Do not install src or ports from CD/DVD/USB media when installing the
OS. Instead, just use csup to pull them down from the 'net. NOTE: If
bandwidth is a concern and you already have a copy of these on another
machine, you can rsync -avH /usr/src and /var/db/sup/src-all from one
machine to another. Don't forget both though (don't just do one
directory and not the other). For ports, /usr/ports and
/var/db/sup/ports-all, obviously.
2. When changing tags/releases in supfiles, do the procedure I
mentioned before doing the "new" (fresh) csup:
rm -fr /usr/src
rm -fr /var/db/sup/src-all
rm -fr /usr/obj/*
csup ...
Finally, the problem you're experiencing could be completely unrelated
to all of the above. I hate to tell you that, but it's possible. You
may have some src.conf or make.conf "tweaks" (e.g. WITHOUT_xxx) that may
be causing problems in the 9.x build infrastructure which didn't break
on 8.x. I'm hoping this isn't the case, but it's possible.
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
More information about the freebsd-stable
mailing list