Re: buildkernel failure because ctfconvert not installed
> On Apr 10, 2020, at 12:57 AM, Poul-Henning Kamp wrote: > > > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov > writes: >> Trond Endrestøl wrote: >>> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: >>> OK, I figured it out. I used to have MK_CTF=no in src.conf, but I recently changed it to WITH_CTF=no. >>> >>> It's either WITH_xxx=yes or WITHOUT_xxx=yes. >> >> Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that >> value is NOT checked: >> >> The values of variables are ignored regardless of their setting; even if >> they would be set to "FALSE" or "NO". The presence of an option >> causes it to be honored by make(1). > > That is not even close to POLA-compliance... > > Obviously negative values ("false", "no") should either be reported as > errors or preferably be respected. > > PS: [This is not the bikeshed you are looking for] > I remember being slightly astonished by the current behavior in the early/mid 2000’s. Then I learned, adapted, and got over it. Change happens, often for the best. Being stuck in the past doesn’t help, and neither does Rodney’s action of berating, belittling, and gaslighting people who don't agree with him. POLA is a good mental check to help guide decisions, but it’s not set in stone. Nothing should be set in stone, we should all be willing and able to evaluate circumstances and make new decisions. Being robotic and set in stone is an excuse for being lazy and/or egotistical. Scott ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
On Fri, Apr 10, 2020, 11:36 AM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > On Fri, Apr 10, 2020 at 10:45 AM Rodney W. Grimes < > > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > > > > > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri > > > Pankov writes: > > > > >Trond Endrest?l wrote: > > > > >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: > > > > >> > > > > >>> OK, I figured it out. > > > > >>> > > > > >>> I used to have MK_CTF=no in src.conf, but I recently changed it > to > > > > >>> WITH_CTF=no. > > > > >> > > > > >> It's either WITH_xxx=yes or WITHOUT_xxx=yes > > > > > > > It's either -DWITH_FOO or -DWITHOUT_FOO. yes or no never enters into it. > > Then we *COULD*, maybe even *SHOULD* check for a value and > complain if one is set. > No. We should not. That breaks other people. > > > > > > > >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states > that > > > > >value is NOT checked: > > > > > > > > > >The values of variables are ignored regardless of their setting; > even > > > if > > > > > they would be set to "FALSE" or "NO". The presence of an option > > > > >causes it to be honored by make(1). > > > > > > > > That is not even close to POLA-compliance... > > > > > > > It took 20 years for someone to notice. If it takes 20 years to be > > astonished, I suspect that it comes close to 'least' by any sane measure. > > I do not see the word *recent* in POLA. > As far as I can tell POLA is time invariant. > Time is relevant. > > > > I am not a fan of it either, not sure when this idea came about > > > of doing WITH_ and WITHOUT and ignoring the set value, but it > > > is very non POLA given how many variables we do have with set values. > > > > > > > We've literally ignored the value for the last 20 years or so (we started > > in the 4.x time frame). This is the first time it's come up. It's hard to > > make a convincing POLA argument based on this data. > > Wrong or bad for 20 years makes it no less wrong. > It's not wrong. > We specifically ignored it because we had crazy s*** in the tree like > > NOSHARED=no meaning something. And it wasn't quite the something you'd > > think it would mean without careful study (it meant do link this shared, > > which is straight forward enough. But it didn't mean do create this > library > > as shared). > > What you call crazy s*** is just double negatives, and though it is > poor it actually has clear symantics. > > You want crazy s*** > WITH_xxx=yes > WITH_xxx=no > do exactly the same thing! Now thats crazy s*** > I didn't read the docs and things broke. > > > > > > > Obviously negative values ("false", "no") should either be reported > as > > > > errors or preferably be respected. > > > > > > > You can't make something foolproof because fools are so ingenious. Also, > > turns out it's trickier to "fix" than you might think. > > It really isnt hard to fix... just stop using, then later allowing a value > on WITH_xxx or WITHOUT_xxx. > It takes them time to find out why the documented thing has changed. Right now we could add a warning if a value is set, people would slowly > weed out this poor use, and in time up the warning to an error. > Not sure this would be popular. Lots of places set some value. This would be way worse. > > > We almost certainly are not going to change this. > Your position, others are free to disagree, as I do. > Others haven't been maintaining the build system. Others didn't carefully negotiate the current behavior among different warring factions as a compromise everyone was happy with. Others haven't been working for 20 years to keep it consistent. So while it is just an opinion, it's one that's informed by long experience with many different issues and scenarios that have come up over time. > Why aren't we going to > > change it? It took 20 years for someone to complain and it may break > > currently working scripts that rely on the documented behavior of the > > variable being defined to define WITH_FOO=n for some crazy reason. And > > this isn't a theoretical example, I know of at least two build systems > that > > define WITH_FOO or WITHOUT_FOO to some value. Also, does WITHOUT_FOO=no > > mean "I don't want foo"? or "I don't not want foo?" So if you don't do it > > for WITHOUT but do to it for WITH, you wind up with another mess of > > inconsistency, or you wind up getting close to have NOSHARED=no again. > > See proposed "change and fix". > I've seen no code. I can't say for sure without looking at the code proposed. Warner > Warner > -- > Rod Grimes > rgri...@freebsd.org > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
> On Fri, Apr 10, 2020 at 10:45 AM Rodney W. Grimes < > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri > > Pankov writes: > > > >Trond Endrest?l wrote: > > > >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: > > > >> > > > >>> OK, I figured it out. > > > >>> > > > >>> I used to have MK_CTF=no in src.conf, but I recently changed it to > > > >>> WITH_CTF=no. > > > >> > > > >> It's either WITH_xxx=yes or WITHOUT_xxx=yes > > > > It's either -DWITH_FOO or -DWITHOUT_FOO. yes or no never enters into it. Then we *COULD*, maybe even *SHOULD* check for a value and complain if one is set. > > > > > >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that > > > >value is NOT checked: > > > > > > > >The values of variables are ignored regardless of their setting; even > > if > > > > they would be set to "FALSE" or "NO". The presence of an option > > > >causes it to be honored by make(1). > > > > > > That is not even close to POLA-compliance... > > > > It took 20 years for someone to notice. If it takes 20 years to be > astonished, I suspect that it comes close to 'least' by any sane measure. I do not see the word *recent* in POLA. As far as I can tell POLA is time invariant. > > > I am not a fan of it either, not sure when this idea came about > > of doing WITH_ and WITHOUT and ignoring the set value, but it > > is very non POLA given how many variables we do have with set values. > > > > We've literally ignored the value for the last 20 years or so (we started > in the 4.x time frame). This is the first time it's come up. It's hard to > make a convincing POLA argument based on this data. Wrong or bad for 20 years makes it no less wrong. > We specifically ignored it because we had crazy s*** in the tree like > NOSHARED=no meaning something. And it wasn't quite the something you'd > think it would mean without careful study (it meant do link this shared, > which is straight forward enough. But it didn't mean do create this library > as shared). What you call crazy s*** is just double negatives, and though it is poor it actually has clear symantics. You want crazy s*** WITH_xxx=yes WITH_xxx=no do exactly the same thing! Now thats crazy s*** > > > > > Obviously negative values ("false", "no") should either be reported as > > > errors or preferably be respected. > > > > You can't make something foolproof because fools are so ingenious. Also, > turns out it's trickier to "fix" than you might think. It really isnt hard to fix... just stop using, then later allowing a value on WITH_xxx or WITHOUT_xxx. Right now we could add a warning if a value is set, people would slowly weed out this poor use, and in time up the warning to an error. > > We almost certainly are not going to change this. Your position, others are free to disagree, as I do. > Why aren't we going to > change it? It took 20 years for someone to complain and it may break > currently working scripts that rely on the documented behavior of the > variable being defined to define WITH_FOO=n for some crazy reason. And > this isn't a theoretical example, I know of at least two build systems that > define WITH_FOO or WITHOUT_FOO to some value. Also, does WITHOUT_FOO=no > mean "I don't want foo"? or "I don't not want foo?" So if you don't do it > for WITHOUT but do to it for WITH, you wind up with another mess of > inconsistency, or you wind up getting close to have NOSHARED=no again. See proposed "change and fix". > Warner -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
On Fri, Apr 10, 2020 at 10:45 AM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri > Pankov writes: > > >Trond Endrest?l wrote: > > >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: > > >> > > >>> OK, I figured it out. > > >>> > > >>> I used to have MK_CTF=no in src.conf, but I recently changed it to > > >>> WITH_CTF=no. > > >> > > >> It's either WITH_xxx=yes or WITHOUT_xxx=yes > It's either -DWITH_FOO or -DWITHOUT_FOO. yes or no never enters into it. > > >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that > > >value is NOT checked: > > > > > >The values of variables are ignored regardless of their setting; even > if > > > they would be set to "FALSE" or "NO". The presence of an option > > >causes it to be honored by make(1). > > > > That is not even close to POLA-compliance... > It took 20 years for someone to notice. If it takes 20 years to be astonished, I suspect that it comes close to 'least' by any sane measure. > I am not a fan of it either, not sure when this idea came about > of doing WITH_ and WITHOUT and ignoring the set value, but it > is very non POLA given how many variables we do have with set values. > We've literally ignored the value for the last 20 years or so (we started in the 4.x time frame). This is the first time it's come up. It's hard to make a convincing POLA argument based on this data. We specifically ignored it because we had crazy s*** in the tree like NOSHARED=no meaning something. And it wasn't quite the something you'd think it would mean without careful study (it meant do link this shared, which is straight forward enough. But it didn't mean do create this library as shared). > > Obviously negative values ("false", "no") should either be reported as > > errors or preferably be respected. > You can't make something foolproof because fools are so ingenious. Also, turns out it's trickier to "fix" than you might think. We almost certainly are not going to change this. Why aren't we going to change it? It took 20 years for someone to complain and it may break currently working scripts that rely on the documented behavior of the variable being defined to define WITH_FOO=n for some crazy reason. And this isn't a theoretical example, I know of at least two build systems that define WITH_FOO or WITHOUT_FOO to some value. Also, does WITHOUT_FOO=no mean "I don't want foo"? or "I don't not want foo?" So if you don't do it for WITHOUT but do to it for WITH, you wind up with another mess of inconsistency, or you wind up getting close to have NOSHARED=no again. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
> > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov > writes: > >Trond Endrest?l wrote: > >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: > >> > >>> OK, I figured it out. > >>> > >>> I used to have MK_CTF=no in src.conf, but I recently changed it to > >>> WITH_CTF=no. > >> > >> It's either WITH_xxx=yes or WITHOUT_xxx=yes. > > > >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that > >value is NOT checked: > > > >The values of variables are ignored regardless of their setting; even if > > they would be set to "FALSE" or "NO". The presence of an option > >causes it to be honored by make(1). > > That is not even close to POLA-compliance... I am not a fan of it either, not sure when this idea came about of doing WITH_ and WITHOUT and ignoring the set value, but it is very non POLA given how many variables we do have with set values. > > Obviously negative values ("false", "no") should either be reported as > errors or preferably be respected. > > PS: [This is not the bikeshed you are looking for] BLUE! > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov writes: >Trond Endrestøl wrote: >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: >> >>> OK, I figured it out. >>> >>> I used to have MK_CTF=no in src.conf, but I recently changed it to >>> WITH_CTF=no. >> >> It's either WITH_xxx=yes or WITHOUT_xxx=yes. > >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that >value is NOT checked: > >The values of variables are ignored regardless of their setting; even if > they would be set to "FALSE" or "NO". The presence of an option >causes it to be honored by make(1). That is not even close to POLA-compliance... Obviously negative values ("false", "no") should either be reported as errors or preferably be respected. PS: [This is not the bikeshed you are looking for] -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
On Thu, 9 Apr 2020 06:34:08 -0500 Justin Hibbits wrote: > On Thu, Apr 9, 2020, 03:57 Gary Jennejohn wrote: > > > > > OK, I figured it out. > > > > I used to have MK_CTF=no in src.conf, but I recently changed it to > > WITH_CTF=no. > > > > It should be spelled > > WITHOUT_CTF= > > only the existence of WITH_/WITHOUT_ is checked, not the value. > You're right, just having WITHOUT_CTF= in src.conf fixes all my problems. It was fooled by there only being /usr/src/tools/build/options/WITH_CTF. > > > > /sys/conf/kern.post.mk checks whether MK_CTF is no and apparently > > does not invoke ctfconvert if that is the case. > > > > I put MK_CTF=no back into src.conf. > > > > So, now everything works without having cftconvert installed. > > > > -- > > Gary Jennejohn > > -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
Trond Endrestøl wrote: On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: OK, I figured it out. I used to have MK_CTF=no in src.conf, but I recently changed it to WITH_CTF=no. It's either WITH_xxx=yes or WITHOUT_xxx=yes. Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that value is NOT checked: The values of variables are ignored regardless of their setting; even if they would be set to "FALSE" or "NO". The presence of an option causes it to be honored by make(1). /sys/conf/kern.post.mk checks whether MK_CTF is no and apparently does not invoke ctfconvert if that is the case. I put MK_CTF=no back into src.conf. So, now everything works without having cftconvert installed. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: > OK, I figured it out. > > I used to have MK_CTF=no in src.conf, but I recently changed it to > WITH_CTF=no. It's either WITH_xxx=yes or WITHOUT_xxx=yes. > /sys/conf/kern.post.mk checks whether MK_CTF is no and apparently > does not invoke ctfconvert if that is the case. > > I put MK_CTF=no back into src.conf. > > So, now everything works without having cftconvert installed. -- Trond. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
OK, I figured it out. I used to have MK_CTF=no in src.conf, but I recently changed it to WITH_CTF=no. /sys/conf/kern.post.mk checks whether MK_CTF is no and apparently does not invoke ctfconvert if that is the case. I put MK_CTF=no back into src.conf. So, now everything works without having cftconvert installed. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
On Wed, 8 Apr 2020 14:51:14 -0700 John Baldwin wrote: > On 4/7/20 11:32 PM, Gary Jennejohn wrote: > > Has anyone else seen this error? > > > > I tried to build a kernel yesterday, but the build failed while compiling > > modules because ctfconvert was not found. > > > > I've had WITH_CTF=no in my src.conf for years, so neither ctfconvert nor > > ctfmerge were installed. > > > > OK, I'll just go to the source dirctories and build and install. > > > > Nope. I got this error: > > make: exec(ctfconvert) failed (No such file or directory) > > and the build failed. > > > > WTF? ctfconvert requires ctfconvert to build? That makes no sense and is > > a real chicken-and-egg problem if I've ever seen one. > > > > I ended up creating /usr/bin/ctf{convert,merge} shell scripts which simply > > did exit 0. That allowed me to finally compile and install the utilities. > > > > Now I'm forced to have WITH_CTF=yes in my src.conf. No big deal. > > > > Still, it seems like the change to the make infrastructure which assumed > > that cft{convert,merge} are always installed was rather premature. > > The change is that GENERIC has 'makeoptions WITH_CTF=yes'. If you build a > kernel without that, you shouldn't need to have ctfconvert installed. This > does mean you need to use a custom kernel instead of GENERIC. > That is exactly what I found confusing. I tried both with and without CTF in my kernel config file and the build still failed. grep CTF /sys/amd64/conf/ernst_new #makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support #options DDB_CTF # Kernel ELF linker loads CTF data I also have makeoptions MODULES_OVERRIDE="cpuctl msdosfs pseudofs filemon" If I move ctfconvert away then I see this error: cd /usr/src; make buildkernel -- >>> Kernel build for ernst_new started on Thu Apr 9 08:51:06 CEST 2020 -- ===> ernst_new -- >>> stage 1: configuring the kernel -- Kernel build directory is /home/garyj/obj/usr/src/amd64.amd64/sys/ernst_new Don't forget to do ``make cleandepend && make depend'' -- >>> stage 2.3: build tools -- -- >>> stage 3.1: building everything -- sh: ctfconvert: not found *** [cpuctl.o] Error code 127 make[4]: *** cpuctl.o removed make[4]: stopped in /usr/src/sys/modules/cpuctl .ERROR_TARGET='cpuctl.o' .ERROR_META_FILE='/home/garyj/obj/usr/src/amd64.amd64/sys/ernst_new/modules/usr/src/sys/modules/cpuctl/cpuctl.o.meta' So, without ctfconvert installed buildkernel ALWAYS fails to build the modules no matter what CTF options are used in the kernel config file. In contrast, buildworld does still work without ctfconvert. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
On 4/7/20 11:32 PM, Gary Jennejohn wrote: > Has anyone else seen this error? > > I tried to build a kernel yesterday, but the build failed while compiling > modules because ctfconvert was not found. > > I've had WITH_CTF=no in my src.conf for years, so neither ctfconvert nor > ctfmerge were installed. > > OK, I'll just go to the source dirctories and build and install. > > Nope. I got this error: > make: exec(ctfconvert) failed (No such file or directory) > and the build failed. > > WTF? ctfconvert requires ctfconvert to build? That makes no sense and is > a real chicken-and-egg problem if I've ever seen one. > > I ended up creating /usr/bin/ctf{convert,merge} shell scripts which simply > did exit 0. That allowed me to finally compile and install the utilities. > > Now I'm forced to have WITH_CTF=yes in my src.conf. No big deal. > > Still, it seems like the change to the make infrastructure which assumed > that cft{convert,merge} are always installed was rather premature. The change is that GENERIC has 'makeoptions WITH_CTF=yes'. If you build a kernel without that, you shouldn't need to have ctfconvert installed. This does mean you need to use a custom kernel instead of GENERIC. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure
On 11/16/15, Shawn Webb wrote: > Hey All, > > I'm experiencing a buildkernel failure only when doing a multi-job build > (-jN). Doing a single-job build works fine. Below is the error I'm > getting. > > Begin Log > In file included from > /usr/src/sys/modules/tests/framework/../../../tests/framework/kern_testfrwk.c:34: > /usr/src/sys/sys/bus.h:655:10: fatal error: 'device_if.h' file not found > #include "device_if.h" > ^ > 1 error generated. > mkdep: compile failed > --- .depend --- > *** [.depend] Error code 1 > > make[4]: stopped in /usr/src/sys/modules/tests/framework > End Log And some more occurrence: http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/299/console http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/298/console http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/297/console And when building fine: http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/300/console > > Thanks, > > -- > Shawn Webb > HardenedBSD > > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure
pcic isn't supported with NEWCARD yet :-) I'll fix it none-the-less. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: buildkernel failure (-Werror)
On 06-Sep-2002 Nate Lawson wrote: > Change introduced by peter disables NO_WERROR: > src/sys/conf/kern.pre.mk: 1.16 > > Change introduced by jhb reintroduces the need for it: > src/sys/i386/pci/pci_cfgreg.c: 1.90 > >:) > > (Seriously, it would be nice if 1.16 was reverted -- sometimes we need > this switch.) I'll fix by moving this under bootverbose and enabling it. > -Nate > > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- > -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica > -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL > -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 > -DGUPROF -mpreferred-stack-boundary=2 -ffreestanding -Werror > -finstrument-functions -Wno-inline /usr/src/sys/i386/pci/pci_cfgreg.c > cc1: warnings being treated as errors > /usr/src/sys/i386/pci/pci_cfgreg.c:517: warning: `pci_print_route_table' > defined but not used > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/MOE. > *** Error code 1 > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message