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

From: Marc Tooley <netbsdMLpostNO@spam.quake.ca>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/36168: usr.bin/config without ecalloc/friends is harder to compile on older hosts
Date: Wed, 18 Apr 2007 15:15:42 -0700

 >  On Wed, Apr 18, 2007 at 07:10:00PM +0000, Marc Tooley wrote:
 >  > >Fix:
 >  >
 >  > 	Back out the removal of the functions, I guess. Tests here
 >  > indicate it seems to work just fine.
 >
 >  This is hardly a bug. With even older systems (pre gcc 3.3) you
 > won't be able to compile the kernel - not a lot different to this
 > scenario.
 >
 >  "build.sh tools" is your friend, sorry about the inconvenience.
 >
 >  Martin
 
 I'm aware it's not a bug/malfunction. I'm also aware of build.sh. It's 
 part of the reason I was forced to create another 10k build script that 
 cleans up after every update/build cycle when iterating through the 
 eight individual arch/version combos I track. build.sh isn't so 
 friendly.
 
 This problem was send-pr'd because:
 
 . it's yet another barrier to classic-style kernel compilation; a 
 barrier that didn't exist prior to the unnecessary removal of those 
 functions.
 . it increases inter-dependencies unnecessarily
 . an entire tool chain shouldn't need to be rebuilt if the host machine 
 provides an adequate compiler.
 . make'ing manually one step harder for all machines older than.. Aug 
 2006. "UPDATING" does not mention this.
 
 In essence, this send-pr is the "I've been solving little problems like 
 this for hours now. Here's the one that exceeded my patience 
 threshold."
 
 I guess my point was, why increase complexity this way? The functions 
 are perhaps two lines a piece, so what is lost by making config(1) as 
 self-contained as possible by rolling back part of this change? 
 Honestly: ecalloc()?
 
 Now people like me must expend additional effort to maintain a parallel 
 source tree if we wish to continue building fresh kernels as documented 
 here:
 
 http://www.netbsd.org/Documentation/kernel/#how_to_build_a_kernel
 
 ... but without the enormous build.sh overhead or the enormous system 
 upgrade overhead.
 
 I'm cognisant of the risks of using an older toolchain to build a new 
 software; however, since the kernel itself is essentially monolithic it 
 doesn't necessarily follow that the environment should make this much 
 of a difference to kernel compilation as it does to userland. 
 Meanwhile, we now have a needless libutil dependency apparently in the 
 name of code consolidation.
 
 I'm not talking about prehistoric machines either. I realise there's a 
 point in time prior to which it's impossible to build a recent kernel. 
 Still, changes like this decrease the ability of hobbiests to 
 track -current. Not all of us can afford to spend the rapidly 
 increasing amount of time necessary to participate in this particular 
 march of progress.
 
 For the record, this machine can compile a -current kernel just fine. 
 3.99.23 was stocked with gcc 4.1.2, and the resulting kernel (after I 
 fixed config) appears to boot on the target hardware.