misc/70532: make buildworld broken in libbsnmp

[Ruslan Ermilov]

The following reply was made to PR misc/70532; it has been noted by GNATS.

From: Ruslan Ermilov <ru at FreeBSD.org>
To: Charlie & <root at pakprotector.com>
Cc: bug-followup at FreeBSD.org
Subject: Re: misc/70532: make buildworld broken in libbsnmp
Date: Mon, 16 Aug 2004 15:46:59 +0300

 On Mon, Aug 16, 2004 at 08:42:21PM +1000, John Saunders wrote:
 > 
 > >Description:
 > 
 > 	make buildworld has been broken for about a week in libbsnmp.
 > 	5 cvsup's and builds over the last week produces the same
 > 	identical fault.
 > 
 > ===> lib/libbsnmp/modules
 > ===> lib/libbsnmp/modules/snmp_atm
 > cat /usr/src/lib/libbsnmp/modules/snmp_atm/../../../../contrib/ngatm/snmp_atm/atm_tree.def /usr/src/lib/libbsnmp/modules/snmp_atm/atm_freebsd.def | gensnmptree -e begemotAtm > atm_oid.h
 > line 110: junk after closing ')'
 > context: "1 internet
 > *** Error code 1
 > 
 > Stop in /usr/src/lib/libbsnmp/modules/snmp_atm.
 > *** Error code 1
 > 
 > Stop in /usr/src/lib/libbsnmp/modules.
 > *** Error code 1
 > 
 > >How-To-Repeat:
 > 
 > 	cvsup to the latest abd make buildworld. I have tried 5 cvsup's
 > 	and builds over the last week with identical failures.
 > 
 > 	Tried make includes as sometimes the build tree picks up
         ^^^^^^^^^^^^^^^^^^^
 
 Please see below why running ``make includes'' is a very bad idea.
 
 > 	includes from /usr/includes when it shouldn't. However this
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 > 	doesn't help.
 > 
 
 buildworld should never use stuff from /usr/include at stage 4.
 If it does, this is a bug.  Please come back to me if you have
 some real facts that it does.
 
 > 	The build line cat's two files together and pipes it into
 > 	gensnmptree and when I run the command manually it too fails.
 > 	Catting the 2 files creates an unparsable file and appears to
 > 	be an error.
 > 
 When you did ``make includes'', it has overwritten your /usr/include
 with fresh copies of header files that do not match your running
 world/kernel.  In particular, you have spammed your /usr/include/osreldate.h
 with a more recent version; now buildworld thinks you're running a
 more recent version of the system than you're actually running,
 including an updated gensnmptree(1) utility, which you don't in fact
 have updated.  You can work around it with this command:
 
 	make buildworld BOOTSTRAPPING=502127
 
 This will cause buildworld to recompile gensnmptree(1) responsible for
 the breakage you're seeing.
 
 
 Cheers,
 -- 
 Ruslan Ermilov
 ru at FreeBSD.org
 FreeBSD committer