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"
buildkernel failure because ctfconvert not installed
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.
--
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"
