Date: Sun, 13 Aug 2000 03:29:00 -0500 (CDT) From: Mike Meyer <mwm@mired.org> To: Warner Losh <imp@village.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Build breakage (was: fail to compile kernel...) Message-ID: <14742.23628.110336.924637@guru.mired.org> In-Reply-To: <200008130714.BAA07153@harmony.village.org> References: <14742.15675.412839.269577@guru.mired.org> <14742.14082.837564.871879@guru.mired.org> <Pine.BSF.4.10.10008131504560.77390-100000@RedDust.BlueSky.net.au> <200008130553.XAA06673@harmony.village.org> <200008130714.BAA07153@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh writes: > In message <14742.15675.412839.269577@guru.mired.org> Mike Meyer writes: > : Warner Losh writes: > : > In message <14742.14082.837564.871879@guru.mired.org> Mike Meyer writes: > : > : The nasty downside of the the module system is that people who don't > : > : adequately test module code before checking it in will screw up kernel > : > : builds for kernels that don't need that code. > : > But I did test it. But I had an uncommitted file on my machine... > : Won't the 'cvs diff' command tell you about such things? If not, > : that's yet another argument for ditching cvs in favor of something > : without so many flaws (like Perforce). > Not when the files are in multiple different directories and you have > mutliple patches cooking in your tree. I committed files in > sys/pccard, but they depended on one in sys/dev/pccard which I > honestly thought I'd checked in with an earlier newcard fix. I'd been > running the patches long enough that I basically forgot. This was > clearly my fault. Hmm - you mean 'cvs diff' can't be pointed at sys to get a list of everything you've touched? > : > : Since you probably don't need the oldcard module. Just comment it out > : > : of /usr/src/sys/modules/Makefile, and rebuild the kernel. You may want > : > : to comment out pccard as well. > : > Or you can just update your sources. There was a 8 hour window where > : > this was broken... > : Well, it was still broken as of about 30 minutes before he asked the > : question. I'd look at it for trivial fixes, then just quit trying to > : build it because I wasn't going to need it. > No. It is not still broken. I committed a fix for this a while ago > (like Friday Morning after breaking it late Thursday night) and have > done a buildworld and a kernel build on a different machine since then > on fresher sources. If it truely is still broken, I need to know what > you did. I just now grabbed the latest sources, and got the following: cc -O -pipe -march=pentium -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c /usr/src/sys/modules/oldcard/../../pccard/pccard.c cc -O -pipe -march=pentium -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c /usr/src/sys/modules/oldcard/../../pccard/pcic.c /usr/src/sys/modules/oldcard/../../pccard/pcic.c:1020: `card_get_memory_offset_desc' undeclared here (not in a function) /usr/src/sys/modules/oldcard/../../pccard/pcic.c:1020: initializer element is not constant /usr/src/sys/modules/oldcard/../../pccard/pcic.c:1020: (near initialization for `pcic_methods[16].desc') *** Error code 1 Stop in /usr/src/sys/modules/oldcard. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/src/sys/compile/EVE. > In fact, I did an cvsup and a cvs update and was able to build a > kernel and modules w/o any problems on my -current box. > > : I didn't mean to finger you particularly. It's just a bit upsetting to > : realize that I can't remember the last time I managed to do an update > : to -current without some kind of breakage. I realize that -current > : isn't guaranteed to build, but that's a bit ridiculous. I mean - I was > : pleasantly surprised that I could build the world first time out. To > : find the kernel breaking for a module that I have no absolutely no use > : for on this machine was a bit upsetting. > Well, that's the break's of -current. sometimes things are broken. > Sometimes when you update, you get burned. Usually it just works. If it usually "just worked", it wouldn't be a problem. I expected to have systems that would at times be a bit delicate for a time, or require old kernels, or the like. What I *didn't* expect was that the usual update procedure would be get new sources, watch the build fail, fix it if possible, or post a note to -current and repeat the process when someone claimed it was fixed. > : I'm beginning to wonder if I shouldn't use -stable as a buffer, and > : just let the committers deals with things not being up to -current. Or > : maybe check to see if the other *BSD's aren't a bit more demanding of > : committers. > I know that you are frustrated, but I think that's unfair. You'll > likely find that the other BSD's are just as bad at times as we get > around here. At least that's my firsthand experience with them as a > committer. There was a period of about 6 months that every time I > went to upgrade the OpenBSD/arc installed on my Deskstation rPC44, > someone had broken something and I had to fix it before it would > compile. That may be true - which would mean it wouldn't be any better than FreeBSD has been for the past few months. Or any worse. On the other hand, breaking the build on other projects I've worked on was considered a major blunder. That doesn't seem to be the case here. > If you aren't a developer or have another compelling reason to track > -current, track -stable. Well, I was hoping to chase out the last of the bugs in the usb modem driver, and possibly try and recover some of the functionality lost when the snd drivers quit working. But the latest version of the former isn't in the tree yet, and new sound cards are cheaper than the time to work on the latter (if only the documentation on pcm did and didn't support were accurate). That was the justification for my converting to -current in the first place. I figured I'd track -current to make the lifes of the people actually committing the code easier, but that seems sort of pointless. <mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14742.23628.110336.924637>