Does "makeoptions WITH_CTF=yes" actually work?

Alexander Leidinger netchild at
Fri Apr 16 13:51:54 UTC 2010

Quoting Navdeep Parhar <nparhar at> (from Wed, 14 Apr 2010  
11:35:40 -0700):

> Have you or anyone else ever used buildkernel successfully with
> "makeoptions WITH_CTF=yes" in the conf file?  Something as simple as
> this does not work for me:

Copy&paste patch, tabs probbly mangled:
Index: Makefile.inc1
--- Makefile.inc1       (revision 206700)
+++ Makefile.inc1       (working copy)
@@ -314,7 +314,7 @@

  # kernel stage

@@ -780,7 +780,7 @@
         @echo "--------------------------------------------------------------"
         cd ${KRNLOBJDIR}/${_kernel}; \
             MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \
             -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile
  # XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case.
  .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) &&  

This lets the buildkernel generate ctf info in the object files (the  
build is not finished yet, so I still have to verify that the final  
kernel contains them too, but I do not see a reason ATM why this  
should not be the case).

If your build environment is faster (here: about an hour for the  
buildkernel), can you please help testing? A buildworld with and  
without WITH_CTF in src.conf, and for buildkernel the same (with and  
without WITH_CTF in src.conf, and for each with and without  
makeoptions WITH_CTF=yes in the kernel). The expected outcome is no  
CTF when no WITH_CTF is in src.conf (except for the buildkernel with  
the makeoptions), and always with CTF when WITH_CTF is in src.conf  
(alternatively only CTF if makeoptions is used, but this would be  
surprising for me).

And then... NO_CTF=yes defined in src.conf and WITH_CTF too... for the  
world this should not produce CTF data, but for the kernel I'm not  
sure what will or should happen for the makeoptions case...


--  Alexander @ PGP ID = B0063FE7     netchild @  : PGP ID = 72077137
See, these two penguins walked into a bar, which was really stupid, 'cause
the second one should have seen it.

More information about the freebsd-current mailing list