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 j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"