Date: Sun, 12 Dec 1999 15:24:43 -0600 From: Karl Denninger <karl@Denninger.Net> To: freebsd-hackers@freebsd.org Subject: Reminder - changes to sources and such Message-ID: <19991212152443.A80500@Denninger.Net>
next in thread | raw e-mail | index | archive | help
Hi folks, Just something to keep in mind.... I am trying to update from a Juneish -CURRENT to a current -CURRENT. I've run into two instances (the latest being the use of "colldef" in /usr/src/share/colldef) where older binaries are INCOMPATIBLE with the newer files they are processing, AND the "make buildworld" target uses the OLD binary in an attempt to read the NEW file. This blows up, obviously. Isn't this a dependancy that should be caught? More specifically, shouldn't the "buildworld" target build /usr/src/usr.bin, bin, sbin, etc FIRST - and THEN rebuild things in share USING THE OBJECTS IT JUST BUILT? I've run into this before with the control files for make in /usr/share/mk being read for a "buildworld", and if they are far enough out of date you get screwed by them - but this is the first time I've seen it with general utilities and share directory where things have to be run through a table processor. Having been bit twice now in my most recent attempt to update by this, I thought I'd post here and see if this is expected behavior or not, and if I'm missing something in the "correct" steps to take to run a buildworld. I would *expect* that in general I should be able to rm -rf /usr/src and /usr/obj, "cvs co src" from the /usr directory, cd into there, and type "make buildworld" and have it complete with *NO* outside dependancies except what is necessary to bootstrap the compiler initially (that is, a working compiler to build the compiler with.) If I can't do this then updating a system in the general case to the current software simply isn't possible without manual intervention. Am I missing something here? -- -- Karl Denninger (karl@denninger.net) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991212152443.A80500>